Leaderboard

Долго у меня напрашивался этот цикл статей и вот наконец изливаюсь. А цикл этот вот о чём. Вёрстка и верстальщик. Основы профессии если хотите и логика действий при вёрстке. Решил разделить пока на две статьи. И предлагаю ознакомится с первой. Верстальщик кто-он? И так поехали. Не хотелось бы скатиться до популизма и повторения много раз описанных истин, поэтому постараюсь писать как можно понятнее и всё-таки передать мысль закладываемую в текст. В сети множество примеров статей и вообще материала о принципах вёрстки, инструментах, методиках написания кода, семантике и т.?д. Но я ещё ни-разу не встречал статьи рассказывающей о том с какого бока подойти к этому процессу, с чего лучше начать и по какому пути двигаться. Наблюдая год от года молодых верстальщиков и вебпрограммистов, совершающих одни и те же ошибки, такая статья просто проситься к написанию. Поэтому в следующем наборе букв постараюсь описать принципы и так сказать мыслительные процессы которые надо вырабатывать в себе для того чтобы начать двигаться с мёртвой точки новичка до специалиста в своём деле. Я не претендую на то, что описанные мною алгоритмы мышления и действий являются истиной в первой инстанции и только так и надо делать. Нет ни в коем случае! Для каждого верстальщика или же веб программиста существует своя истина и свои принципы. Всё-таки все мы люди и все ходим по своим дорогам. Но основные алгоритмы у нас всех одинаковые и отличаются только методом изложения и внедрения. Хотелось бы донести одну не тривиальную мысль к пониманию которой приходишь только с опытом и количеством реальной работы в каждом из этапов проекта. Верстальщика нельзя назвать чем-то самостоятельным в команде, единицей мнением которой можно пренебречь или как говориться сработать в слепую, отдал макет, получил страницу (К сожалению-это самый частый случай на ниве фриланса). Как правило из такой работы ничего хорошего не получается. Потому-что верстальщик работает не зная под что и не понимая идеи проекта, а это ведёт к тому что программист получает сложности с внедрением вёрстки в код, копирайтер обнаруживает нехватку или избыток стилей и элементов усложняющих ему жизнь. Сеошник сталкивается с грязью в коде или же не возможностью выстроить необходимое семантичное ядро на странице. В результате всем участникам проекта приходится либо чем-то жертвовать, либо переделывать кучу не профильной работы. Что в свою очередь ведёт к удорожанию проекта или к увеличению сроков проекта. На верстальщика возлагается очень большая ответственность которой нет ни у дизайнера, ни у программиста. Верстальщик своего рода «серый кардинал» проекта, перехватывающий «эстафетную палочку» у менеджера проекта, на стадии от-рисованного макета и параллельно его работе координирует техническую составляющую. По неволе верстальщику приходиться касаться почти каждого этапа проекта и учитывать получаемые рекомендации в своей работе. Как однажды сказал один мой друг. Верстальщик это руки которые складывают бутерброд, от них зависит в каком порядке будут размещены ингредиенты!© Поэтому не бойтесь брать на себя эту ответственность и в теневом режиме координировать исполнение проекта. Не бойтесь думать и отстаивать своё мнение, не бойтесь вносить хотя-бы мелкие поправки в проекты которые вам приходиться делать. В этом ваше предназначение как верстальщика и если вы решаете сделать это увлечение делом вашей жизни, то несите эту ответственность с честью. Поэтому думайте, думайте и ещё раз думайте, в этом залог роста. Прежде чем начать что-то делать потратьте хотя-бы пару минут на то чтобы продумать, как это сделать, затем ещё пару минут на то чтобы продумать, как это сделать лучше, чем сделали бы другие и даже после того когда вроде бы вы уже всё придумали и нарисовали себе в голове идеальную разметку, потратьте ещё с десяток минут на то чтобы ясно себе представить процесс и его реализацию. Прогоните через мозг каждый не очевидный и очевидный элемент макета, каждую строчку кон-тента и каждый блок на странице. Выведите общую формулу проекта распределив по своим группам повторяющиеся элементы и части которые эксклюзивные для страницы. Не надо этого делать на бумаге, приучите себя делать это в голове. Оценивать макет и проект в целом с одного лишь взгляда. Приучите себя понимать то, что вам предстоит сделать, подмечая какие подводные камни встретятся на пути, какими техниками вам придётся воспользоваться и что займёт больше всего времени. Вот с этого пожалуй и должна начинаться любая вёрстка, любого макета. С продумывания и оценки своей будущей работы. Простой ли он, или много-колоночный, резиновый, статичный, под какой тип устройств, на какой платформе и какие браузеры будут его рендерить. Прикиньте вес каждой страницы в отдельности и подведите его под критический порог. Соотнесите на сколько удастся соблюсти стандарты и придётся-ли использовать сторонние технологии для реализации интерфейса. Возьмите на заметку под какую CMS необходима вёрстка и какие её особенности надо учесть. Определите основное семантическое видение страницы. Если есть ТЗ, то вооружившись им, составьте карту страницы с описанием главных и второстепенных блоков, основных заголовков и их подзаголовков. Определите, где, какой тип кон-тента расположен и выстроен ли он в логичном с точки зрения семантики порядке. Какие варианты изменения в содержимом должны выдержать контентные блоки, на сколько макет восприимчив к эволюции содержимого, которое может появиться со-временем на страницах, существование каких элементов надо предусмотреть на будущее. Не бойтесь если в процессе оценки макета вы поймёте что многих вещей дизайнер банально не продумал или не предусмотрел. Как правило, при коллективной работе, дизайнер при от-рисовке макета плотно советуется с верстальщиком, также как верстальщик консультируется у программиста, создавая тем самым естественную цепочку производства. Поэтому обоснованные поправки к макету должны быть учтены дизайнером. На своём веку я много повидал дизайнеров и мало кто отказался от внесения поправок в макет, естественно что они были аргументированы и внесены до предоставления макета заказчику. Хотя случается и такое что работа ведётся разрозненно, тогда аргументы необходимо высказать заказчику напрямую, пояснив с какими трудностями, в будущем, он столкнётся при сборке проекта программистом и продвижении или поддержке проекта. Старайтесь упрощать жизнь себе и тем, кто будет работать над проектом в дальнейшем. Думаю я немного отклонился от темы и ушёл-таки в популизм. Но об этом нельзя было не сказать. Наблюдая как многие молодые верстальщики словно во тьме роются в тегах, забывая про идею и саму суть своей профессии. В следующей части постараюсь более подробно описать логику действий и принцип принятия решений на конкретном примере, будем верстать проект публично)))

HTML5 — это продолжение и расширение как HTML4.01, так и XHTML1.x. Собственно, они и раньше различались по сути только синтаксисом, а в HTML5 "синтаксис — ничто, семантика — всё", и их пути снова сошлись. При text/html равно правильны оба синтаксиса. И application/xhtml+xml в HTML5 сохранен (причем доктайп там вообще не нужен!). Больше того, новые браузеры (Хром 7+, FF4+, вот-вот выходящая Опера 12) вообще не знают никакого другого HTML, кроме HTML5 (без разницы, что там где в доктайпе написано). Так что, независимо от формального утверждения стандарта академической тусовкой, индустрия в целом выбор сделала. Единственная проблема — валидация. Небольшие "косметические" изменения в спеке еще бывают, допустимые значения атрибутов добавляют/удаляют (теги — имхо, уже вряд ли), поэтому вчера валидная страница может завтра стать вдруг чуть-чуть невалидной. Но это касается новых экспериментальных вещей, то, что уже работает в >2 браузерах, работать вряд ли перестанет. А вообще новый стандарт специально построен так, что валидная страница XHTML 1.0 Strict, скорее всего, также будет валидной HTML5-страницей (с точностью до доктайпа и пары-тройки атрибутов). Только с HTML5 можно не бояться, что валидация идет по одним правилам, а реальный разбор в браузерах — по совсем другим.

Лучше всего использовать мозг. А если его нет?

можна!должно работать <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Документ без названия</title> </head> <body> <input type="button" value="opa4a" disabled="disabled" /> <script> function opa(){ x=document.getElementsByTagName('input')[0] x.disabled=false } setTimeout("opa()",1000) </script> </body> </html>