1. Если легко придумывается адекватный текст для alt, то нужно делать картинкой
2. картинки фоном в CSS — это крайняя мера, потому что “обнаруживать их в CSS – это не прозрачно”
3. когда стили отключены, кнопка должна отображаться как кнопка
4. представить, что все img на странице проиндексируются поисковиками и будут выдаваться в поиске по картинкам. Иногда помогает сориентироваться, где уместно использовать тег img /, а где – фончик в css.

На самом деле вопросов, связанных с логикой и семантикой вёрстки возникает много и не все они решаемы (или легко решаемы), где-то знаний не хватает, где-то хорошие тенденции рубятся “корпоративной политикой” или просто выбором технологий. Там же, в комментах к тому же посту несколько раз попросили дать ссылки на некоторые наши проекты, я уже как-то писала и ещё раз напишу: извиняйте, ребятки, не дам. Но задумалась о том, что вовсе не на всех наших проектах такое пристрастное требование верстать дивами, да ещё и обращать внимание на логику кода и семантические тонкости.

Действительно, если сложилось впечатление, что мы тут эти… фанаты исключительно дивной вёрстки, то оно правильное только отчасти. А потому, что удовлетворять пристрастие к правильному коду получается на сегодняшний день только для части проектов, для рекламных сайтов (которых много, не скрою), небольших проектов из конечного количества страниц и с заведомо известной структурой, предварительно (и гарантированно) утверждённой ДО НАЧАЛА ВЁРСТКИ. Но не все проекты у нас такие везучие. Как только речь заходит о не однотипных рекламных сайтах, а, к примеру, о каких-то сервисах-тулзах, то просто не получается. Прежде всего потому, что как правило утверждённого проекта на наши сервисы-тулзы мы не имеем, разработка происходит по накопительной модели.

К примеру разрабатывается каркас сервиса, с какой-то базовой функциональностью. Для того, чтобы презентовать его учредителям компании и/или инвесторам, его надо визуально “причесать”. Придумывается какой-нибудь дизайн, отвёрстывается макет, тюнится движок, на этом этапе вёрстка, как правило, ещё приличная, т.е. без костылей и практически всегда – без хаков. Дальше (в случае если) после презентации проект начинает бурно развиваться, разными программерами, работа верстальщика – подтюнить то, что напрограммировали программеры, в рамках же существующего дизайна. И вот здесь начинаются грабли, которые заканчиваются тем, что через пару месяцев на когда-то стерильный код просто страшно смотреть: костыли на костылях, сплошные хаки для хоть какой-то кроссбраузерности, вылазят такие требования к “элементам оформления”, которые в концепцию изначальной сетки просто не помещаются. Да, и таблицы. Мы как будто бы умеем верстать довольно сложные макеты без таблиц, но не тогда, когда невозможно предсказать требований к макету через день или уж тем более через месяц. Да, запускаем табличный каркас под основную модульную сетку (ну почти всегда). И здесь единственное решение – затребовать время на полную перевёрстку проекта. Написать с нуля, описать по-другому модульную сетку, продуманно и грамотно, сделать совершенно другие цепочки наследований свойств, убираются здоровенные избыточные конструкции, которые при изначальной модели и убрать-то нельзя, много всего посыпется. Но это не столько от безграмотно построенной первоначальной модели html+css, сколько от того, что со временем изменяется сама концепция. Кто-то может сказать, что это уже к вопросу проджект менеджмента, мол, должно же быть какое-то ТЗ, в рамках которого разработчики ваяют свои шедевры. Здесь я вижу две проблемные стороны:

1. Да, основное – это организационная проблема, когда всё ТЗ состоит из рекомендаций и пожеланий, которые просто добавляются по ходу разработки, когда продуманные изначально, скажем 5 разделов через пару месяцев дорастают до 10 и уже не вписываются в разработанную изначально модульную сетку, когда сама архитектура проекта меняется несколько раз принципиально и не только “а давайте добавим ещё парочку разделов в главную навигацию”, и “а почему бы быстро не сделать мультиязычность” (правда ведь никого не волнует, что в изначальном макете не особо было предусмотрена такая беда и, в частности, то, что количество букв в названиях, скажем, элементов меню на английском, немецком и французском иногда ну о-о-очень сильно разнится), когда каждый тим лидер в рамках озвученных пожеланий сам себе аналитик, когда спустя пол года проект уже ничем – ни визуально, ни по функциональности не напоминает тот сентябрьский, который презентовался в первой версии.

2. С другой стороны обычное дело в современных условиях разработки: всегда всё нужно сразу, всегда всё должно быть интуитивно понятно и без написанного плана проекта, стартап заявляет о себе базовой функциональностью, и уже после того, как становится интересен аудитории (а значит и инвесторы найдутся без особых проблем) внимает всем пожеланиям пользователей и расширяет свою функциональность, так сказать, по ходу дела. И здесь с одной стороны никому не интересны капризы верстальщиков, у которых на глазах разваливается продуманная для первой версии проекта модель – нужно быстрее, нужно сразу, нужно бежать, бежать в два раза быстрее хотя бы для того, что бы остаться на рынке. Здесь единственное разумное решение – дождаться того, что на каком-то этапе гонка закончится хотя бы незначительной паузой и руководство выделит человеко-часы на редизайн и ревёрстку всего проекта с нуля.

По второму пункту – да, вот прямо сейчас именно этим мы и занялись по одному из наших сервисов. Который начинался с двух простеньких контролов, работающих с простенькой базой данных. Там тоже была головная боль с тем, что заказчик точно не знал, чего же ему на самом деле хочется, но получив ту самую базовую функциональность, начал хотеть всё больше и больше, а сделать это было реально, добавлялись разделы, тулзовые панели, отчёты и фильтры, многопользовательский доступ и прочие пряники. Изначальная вёрстка, такая стерильная, логичная, семантичная, была забыта усложнившейся нереально модульной сеткой, таблица стилей выросла до кучи файлов с кучей же избыточных описаний и кривых наследований, но скоро, уже скоро всё изменится. Проект почти год крутился у клиента в том самом, более-менее законченном состоянии, работающий и внешне опрятный, но на вёрстку и стили я без содрогания смотреть уже не могла. И вот клиент созрел на полный редизайн, функциональность, кажется, меняться, во всяком случае принципиально и в ближайшее время не будет. Сделаем конфетку

Так что по поводу холиворов на тему табличной и дивной вёрстки – да, мы ищем лёгих путей и как только у нас начинается очередное “стремительное развитие”, идём на компромиссы, таблицы используем и для каркасов и для оформления сложных форм, на более-менее предсказуемых же макетах в табличной вёрстке просто нет необходимости. Когда мы верстаем сайты, которые без дотнетовских движков, безтабличной вёрсткой ещё можно похвастаться, но как только речь заходит о дотнетовских проектах, то вопрос становится неактуальным, потому что кто в теме, тот и без меня знает, что такое дотнетовские контролы типа гридов или листвьювов, календарей или прочих “продвинутых” решений и во что они рендерятся в браузере. Ага, правильно! Таблицы в таблицах в таблицах. Т.е. полюбому приходится в таблицах стилей описывать элементы модульной сетки, построенные на табличной вёрстке. Это реальность, от которой никуда не денешься, разве только что если сменить компанию, где в качестве базовой технологии разработки используется что-нибудь другое.

Ну и на последок – примеры-частности. Ага, визуальные редакторы контента веб-страниц. Сделали замечательный такой сервис для мини-социальной сети (там закрытая группа, мало кому будет интересно), отличненько. По ТЗ мы делаем только каркас (топ, навигация, панель с тулзами), а содержание информационных страниц создают редакторы сервиса. Поставили им для начала простенький редактор – цвет текста поменять, картинку вставить, абзацы-ссылки-списки, конечно же, режим редактирования без визуальных средств чистый html, что людям нужно ещё для полного счастья? Им нужен продвинутый визуальный редактор типа как у word`а! Некоторое время пробовали уговорить, объясняли, какой бардак сейчас начнётся, не объяснили. Они захотели вот этот со всеми включенными тулбарами.

Разумеется уже через неделю раздались крики по поводу того, что у них на всех страницах (кроме главной), где они добавили своё содержание, разъехалось ВСЁ. Захожу в проект, смотрю, что они там намудрили, и не понимаю – зачем им весь этот расширенный тулбар, если они всё равно в визуальную зону вставляют форматированное нечто из того же word`а? Где у них образовалась таблица в таблице фиксированной ширины на 1500 пикселей и куча вторичного чиста word`овского кода в тегах? Предложили им простое решение – в контейнере, куда они грузят свой контент, добавить описание класса что-то типа overflow:auto;, не-а, говорят, не подходит. Не красиво. Полосы прокрутки не предусмотрены в концепте. Написали им документаху – чем можно пользоваться, чем нельзя и куда смотреть если что. Не помогло опять. Просто с какой-то периодичностью приходится заходить к ним с админскими правами и чистить тот код, который они очередной раз вставили в качестве обновлённого контента своих страниц.

Вот ещё замечательный пример: на ярушке один из верстальщиков глубокоуважаемого Яндекса Вадим Макишвили запостил провокационный пост про таблицы в макетах:

Не существует сейчас надежнее средства для создания сложной раскладки, чем таблица. Под надежностью я понимаю:
- уверенность в правильном поведении раскладки
- уверенность, что последующая модификация раскладки не принесет часов геморроя
- скорость разработки раскладки
Плюйтесь в меня желчью, фанаты семантики. Плюйтесь-плюйтесь… Когда вам доверят верстать портальные морды, которые обложены главным требованием — “ничего никогда не должно сломаться” — вернётесь к раскладе таблицами.

На сегодняшний день 139 комментариев, некоторые не безинтересно почитать; в частности, о резиновых каркасах, о различных ограничениях по ширине (Виталий Харисов: “В данном конкретном случае возможно. Не задавай max-width вообще. Если ты дебил и разворачиваешь окно браузера на максимум на 30″ мониторе, то тебе ничего не поможет.“) и о том, кто должен продумывать тот или иной тип макета и поведение блоков на странице.

Предыстория такая. Наши украинские дизайнеры (типа младшая группа) рисовала много эскизов “в туда”, часть из них проходила, и мы делали по этим эскизам небольшие сайты. При старом арт-директоре были, конечно, расстраивающие недопонимания, плохо была налажена обратная связь, переписка в основном состояла в том, что я ему писала “дайте же наконец хоть какие-то комментарии”, в мессенджере пинала, мол прочти письмо и ответь, получала ответ, что ASAP, и всё, дальше молчание. К вёрстке у нас каких-то конкретных требований не было, кроме как бы и так понятных – валидный HTML, валидный CSS, никаких табличных макетов (это, кстати, по поводу дискуссии про то, что лучше, это другие могут выбирать то или другое или даже дискутировать, а у нас, помимо идеологии и принципов, так было заявлено в ТЗ), по возможности текст делать текстом (ну, если уж совсем декоративные заголовки, то хидерами-подменками с длинными координатами).

Причём все эти месяцы я слышала (и получала известиями в мессенджере) информацию о том, что нам будут высланы какие-то технические требования к макетам, которые мы должны соблюдать. Я периодически напоминала, получала ответ о том, что “да-да, готовится”, а потом первого арт директора уволили и взяли второго, с которым мы общаемся уже скоро месяц как (третью неделю, вроде, или четвёртую). И всё по-новой: мы готовим вам документ с техническими требованиями к верстаемым сайтам, и этот документ будет выслан ASAP. Как в, разумные мои читатели, и сами понимаете, этот документ уважаемые наши заатлантические партнёры так и не прислали, и я даже сомневаюсь в том, что они его досочиняли, и вообще у них в голове есть какая-то типизированная схема, по которой эти требования можно составить.

Бр-р-р опять много букв на вступление, а теперь вопросы:

1. В коротком письме, отосланном (вчера вечером по их канадскому времени или сегодня ночью по нашему) этим вторым арт-директором, было отчаянное требование ОСТАВЛЯТЬ В ОТПРАВЛЯЕМЫХ ОБРАТНО .PSD ДОКУМЕНТАХ СЛАЙСЫ. Опс. Какие слайсы? Это в том смысле, что наши верстальщики не должны были учиться вменяемой вёрстке, а должны были тупо резать скетчи в Image Ready? Вот здесь вопрос. Может я чего-то не знаю про слайсы и удобные инструменты для автопорезки? Последний Image Ready – может, я про него чего-то не знаю? Насколько мне известно, даже в самом настроенном случае, в самом правильном этот красавец генерит либо (очень аккуратную) табличную вёрстку (с RollOver`ами, с готовым скриптом) или же CSS разметку макета с абсолютным позиционированием. Т.е. если его и пользовать как-то, то, получается, только для быстрой порезки фоновых картинок. Может, и правда имеется ввиду быстрая нарезка фончиков, но вдруг нет, вдруг есть какие-то продвинутые инструменты для работы со слайсами? А я отстала от жизни со своей недешёвой ручной работой?

2. Второе письмо зацепило ещё больше. Содержало обиду на то, что этот самый второй арт-директор жалуется на вёрстку в одном из последних сайтов, якобы на то, что кнопка “Download Now почему-то оказалась бэкграундом“. Ну понятно, что по аналогии с предыдущими макетами “Download Now” – это не кнопка, а ссылка (a href), и ведёт она куда надо, и стоит правильно, а вот то, что она такая красненькая декоративная – да, картинка и в самом деле подгружается в таблице стилей для класса ссылки. Потому что фончик у этой ссылки-псевдокнопки – это элемент декора, а не функциональный объект, и вполне логично вынести картинку для фончика в css. Я же так понимаю, что наш этот (второй) арт-директор искал в хрефе именно img src=”" mce_src=”", т.е. объект-картинку, расположенную в объекте-ссылке, которая ведёт на страницу Download. Т.е. в его картине мира такая модель является правильной, а реализованная нами – не верной настолько, что он ПЕРЕВЁРСТЫВАЛ! Ну ладно, я не против, но уж если мы говорим о качественной профессиональной вёрстке, то каким-то образом нужно выяснить, какое решение будет правильным. И почему (по словам нашего партнёра) арт-директор был возмущён нашим решением? Т.е. не просто отметил, как альтернативное, но по каким-то причинам не подходящее, а именно ВОЗМУТИЛСЯ и пожаловался начальству на качество кода украинских верстальщиков?Причём мы-то как раз не против, ежели это есть часть конкретных технических требований (которое мы, как я выше писала, не получали и на словах даже не обсуждали), трудности я не вижу никакой (более того, вообще не понятна проблема с “перевёрстыванием”, посмотрела я последний код, если уж так понадобился в вёрстке тег img, то в его src просто вставляется тот же адрес, который в пути к фону в классе для ссылки, там же всё ясно). Но так ли уж правомерен упрёк именно в недостаточной качественности кода? Это довольно принципиальный вопрос, потому что больше всего в партнёрстве на сегодняшний день расстраивает именно грузилово с упрёками в непрофессионализме — и тут же доступ к работам канадских “профессионалов”, от “качества” которого мы просто теряемся. Как в случае скетчей (у нас “не проходят” очень неплохие работы, очень, но тут же присылаются на вёрстку скетчи, отрисованные канадскими дизайнерами, и мы тихо млеем: совершенно отвратительные скетчи в стиле 90-х годов прошлого века у хомпейджей на narod.ru выглядели зачастую пристойнее, а вёрстка – это просто песня, и я писала уже о качестве ихней вёрстки даже в этом блоге). У нас разное понимание того, что такое качество, и что такое профессиональная вёрстка, это уже ясно. Единственный способ – преодолеть на сегодняшнем митинге (собрание по громкой связи по телефону с их гоп-компанией) желание рассвирепеть и поругаться и попытаться, как бы это выразиться… обсудить конструктивно, обменяться технологическими процессами и знаниями для взаимной пользы и выработать (с обоих сторон) новые правила и критерии качества.

Нет, но пример с псевдокнопкой всё равно следует обсудить здесь, для начала.

Помните, были в недавние ещё времена споры о том, кто такой веб-мастер и что входит в его обязанности? В дискуссиях определились, что веб-мастер – это такой и швец и жнец на все руки мастер, который в небольшой компании и за сервер в ответе, и за общую работоспособность корпоративного сайта, и письма из обратной связи принимает, и для их приёма почту настраивает, и контент обновляет если что. Но может ли быть такое в большой компании, где есть системный администратор, и не один, где есть DBA и тоже не один, где штат саппорта больше сотни человек, а контентщики не имеют вообще никакого отношения к веб-дизайнерам – их обязанности разделены и чётко формализованы? С дизайнерами в маленьких компаниях похожая ситуация – одному человеку в обязанности вменяется и скетчи для веба нарисовать, и сайт отверстать, и флеш на нём забабахать, и базу данных прикрутить, и визитки в полиграфию отправить, и предпечатную подготовку для всех бланков и презентаций компании провести.

В нашей компании какое-то количество лет был один дизайнер – он именно так и назывался (не будем показывать пальцем, хотя, разумеется, это была я) , и это, с позволения сказать, дизайнер рисовал скетчи на сайты, отвёрстывал как простые сайты, так и макеты под шаблоны движков, и стандартных, и нашими же программерами писанных, с дальнейшей адаптацией вёрстки для новых страниц наших развивающихся проектов, рисовал, собирал и тюнил скины для виндовз-приложений, создавал пиктограммы и полноформатные иконки для программ, с программерами же оптимизировал интерфейсы этих же виндовз-программ; а так же периодически вёл переговоры с заказчиками и принимал участие в постановке более-менее внятной задачи для разработчиков. Время идёт, всё меняется как бы к лучшему, теперь в компании есть целый отдел, где более узко заточенные специалисты занимаются всем тем же самым, но задачи для них распределены. Есть несколько рисующих дизайнеров – кто-то специализируется на скетчах для веб-интерфейсов, кто-то на миниграфике, иконках для программ и прочих “элементах” интерфейсов, есть несколько верстальщиков — у кого-то лучше получается собирать самодостаточные сайты (визитки, рекламные, без движка в основном или на стабильном, не дорабатывающемся ежедневно движке), кто-то неплохо освоился в наших дотнетовских проектах и больше верстает с (и за) программерами на новых текущих проектах. Так вот для нашего руководства — была я одна – меня называли дизайнером, а теперь весь наш отдел, всю нашу команду по инерции традиции тоже называют дизайнерами. Потому я так часто использую термины-разделители “дизайнер рисующий” и “дизайнер верстающий”.

При этом если поглубже копнуть в определение термина “дизайнер”, то противоречия здесь никакого нет. Я ведь не просто так последние месяцы писала о качественной вёрстке – да, считаю и приучаю наших верстальщиков, что “дизайн” в смысле “проектирование” имеет непосредственное отношение к их работе. Очень здорово, если ребята умеют анализировать отданный им в работу скетч, продумать оптимальную модульную сетку, спланировать базовый шаблон контейнеров – а не тупо резать скетч на слайсы, запихнув пару фонов в стили и там же в таблице стилей прописав три десятка классов для разного оформления шрифтов (вчера исправляли один из старых наших же проектов, где верстальщик именно так и поступил, а та самая стопка классов, при детальном анализе, была вообще избыточна). Проектирование своей будущей разметки – чем не дизайн?

Кроме того ещё одна особенность замечена (раньше как-то не особо обращала внимание). Если я в нашем корпблоге публикую (или в месенджер отсылаю ссылку на) какую-то сугубо техническую информацию – хаки или красивые решения для css, какие-то особенности стандартных (соответствующих спецификации), но не кроссбраузерных примеров и т.д. – это предназначается только верстальщикам, да и в блоге обсуждают только верстальщики. Если же публикую общедизайнерскую информацию – ссылки на удачные дизайнерские портфолио, интересные заметки о цвете или правильных интерфейсах – отсылаю всем, и рисующим, и верстающим. Что-то мне подсказывает, что развивать чувство прекрасного, чувство гармонии, знать основы композиции будет очень не лишним даже для таких технарей, как верстальщики. Это, конечно, так же к вопросу о не во всём хорошей организации работ в нашем офисе. К примеру, не редкие ситуации, когда проект присылается как бы уже отрисованный и даже отвёрстанный (это кошмар в большинстве случаев), и надо что-то там поправить-причесать, руководство при этом определяет работу как задачу для верстальщика и только; и по выделенным человеко-часам – тоже только верстальщик. Которому, может, и не запрещается обратиться к рисующим “за консультацией”, мол, какой лучше цвет для фончика хидера в этом гриде или достаточные ли отступы у элементов этой формы, но по большому счёту работает он один. Такие кривые задачи приходят не часто, но практика показывает, что заказчики и руководство считают, что здоровое чувство вкуса и здравый смысл – достаточно для того, чтобы верстальщик самостоятельно справился, написал таблицу стилей и доверстал код.

А сейчас появилась потребность в новом “дизайнерском” ответвлении, ещё одной специализации. Я даже не знаю как назвать такого специалиста, и понятия не имею как его тестировать… но об этом в следующем посте. Заканчивая эту тему, хочу сказать, что всё-таки формализация необходима и срочно, потому что часто бывает, что качели нагрузки то клонятся в сторону объёмов для рисующих дизайнеров, то в сторону объёмов для верстальщиков, а руководство, между прочим, оценивает работу отдела в целом и деталями интересоваться отказывается, и фраза “у вас там шесть человек, что, все так заняты? Почему медленно?” звучит не так уж и редко. Объясняться каждый раз, что верстальщик не будет рисовать этот ваш логотип или что рисующая девочка не может поправить поехавшую вёрстку в коде проекта – тяжело и обидно, и здесь уже я начинаю строго следовать формальным определениям, защищая своих красавцев. Но всё равно в глазах руководства наша команда – это отдел дизайнеров, чем бы мы там внутри команды не занимались и как бы не перераспределяли между собой обязанности, вот так вот.