О вёрстке, холиворах и реалиях
Не так давно к посту “Два вопроса про качественный в кавычках CSS” получила много полезных развёрнутых комментариев, спасибо всем. Напомню, что один из вопросов был о том, что если на странице есть кнопка-ссылка, к примеру, “Download”, то как правильно её реализовать: использовать конструкцию <a href=""><img src="" alt="Download" /></a>, где имидж в ссылке - красивая картинка для кнопки, или просто <a href=""></a>, где в описании класса фоном подгружать ту же красивую картинку? Правильно с точки зрения семантики, с точки зрения грамотной вёрстки и т.д. В комментариях были сторонники первого решения, были - второго, большей же частью писали о том, что без принципиальной разницы, по договорённости с главным менеджером. К примеру, заинтересовали такие критерии:
- Если легко придумывается адекватный текст для alt, то нужно делать картинкой
- картинки фоном в CSS — это крайняя мера, потому что “обнаруживать их в CSS - это не прозрачно”
- когда стили отключены, кнопка должна отображаться как кнопка
- представить, что все img на странице проиндексируются поисковиками и будут выдаваться в поиске по картинкам. Иногда помогает сориентироваться, где уместно использовать тег img /, а где - фончик в css.
На самом деле вопросов, связанных с логикой и семантикой вёрстки возникает много и не все они решаемы (или легко решаемы), где-то знаний не хватает, где-то хорошие тенденции рубятся “корпоративной политикой” или просто выбором технологий. Там же, в комментах к тому же посту несколько раз попросили дать ссылки на некоторые наши проекты, я уже как-то писала и ещё раз напишу: извиняйте, ребятки, не дам. Но задумалась о том, что вовсе не на всех наших проектах такое пристрастное требование верстать дивами, да ещё и обращать внимание на логику кода и семантические тонкости.
Действительно, если сложилось впечатление, что мы тут эти… фанаты исключительно дивной вёрстки, то оно правильное только отчасти. А потому, что удовлетворять пристрастие к правильному коду получается на сегодняшний день только для части проектов, для рекламных сайтов (которых много, не скрою), небольших проектов из конечного количества страниц и с заведомо известной структурой, предварительно (и гарантированно) утверждённой ДО НАЧАЛА ВЁРСТКИ. Но не все проекты у нас такие везучие. Как только речь заходит о не однотипных рекламных сайтах, а, к примеру, о каких-то сервисах-тулзах, то просто не получается. Прежде всего потому, что как правило утверждённого проекта на наши сервисы-тулзы мы не имеем, разработка происходит по накопительной модели.
К примеру разрабатывается каркас сервиса, с какой-то базовой функциональностью. Для того, чтобы презентовать его учредителям компании и/или инвесторам, его надо визуально “причесать”. Придумывается какой-нибудь дизайн, отвёрстывается макет, тюнится движок, на этом этапе вёрстка, как правило, ещё приличная, т.е. без костылей и практически всегда - без хаков. Дальше (в случае если) после презентации проект начинает бурно развиваться, разными программерами, работа верстальщика - подтюнить то, что напрограммировали программеры, в рамках же существующего дизайна. И вот здесь начинаются грабли, которые заканчиваются тем, что через пару месяцев на когда-то стерильный код просто страшно смотреть: костыли на костылях, сплошные хаки для хоть какой-то кроссбраузерности, вылазят такие требования к “элементам оформления”, которые в концепцию изначальной сетки просто не помещаются. Да, и таблицы. Мы как будто бы умеем верстать довольно сложные макеты без таблиц, но не тогда, когда невозможно предсказать требований к макету через день или уж тем более через месяц. Да, запускаем табличный каркас под основную модульную сетку (ну почти всегда). И здесь единственное решение - затребовать время на полную перевёрстку проекта. Написать с нуля, описать по-другому модульную сетку, продуманно и грамотно, сделать совершенно другие цепочки наследований свойств, убираются здоровенные избыточные конструкции, которые при изначальной модели и убрать-то нельзя, много всего посыпется. Но это не столько от безграмотно построенной первоначальной модели html+css, сколько от того, что со временем изменяется сама концепция. Кто-то может сказать, что это уже к вопросу проджект менеджмента, мол, должно же быть какое-то ТЗ, в рамках которого разработчики ваяют свои шедевры. Здесь я вижу две проблемные стороны:
1. Да, основное - это организационная проблема, когда всё ТЗ состоит из рекомендаций и пожеланий, которые просто добавляются по ходу разработки, когда продуманные изначально, скажем 5 разделов через пару месяцев дорастают до 10 и уже не вписываются в разработанную изначально модульную сетку, когда сама архитектура проекта меняется несколько раз принципиально и не только “а давайте добавим ещё парочку разделов в главную навигацию”, и “а почему бы быстро не сделать мультиязычность” (правда ведь никого не волнует, что в изначальном макете не особо было предусмотрена такая беда и, в частности, то, что количество букв в названиях, скажем, элементов меню на английском, немецком и французском иногда ну о-о-очень сильно разнится), когда каждый тим лидер в рамках озвученных пожеланий сам себе аналитик, когда спустя пол года проект уже ничем - ни визуально, ни по функциональности не напоминает тот сентябрьский, который презентовался в первой версии.
2. С другой стороны обычное дело в современных условиях разработки: всегда всё нужно сразу, всегда всё должно быть интуитивно понятно и без написанного плана проекта, стартап заявляет о себе базовой функциональностью, и уже после того, как становится интересен аудитории (а значит и инвесторы найдутся без особых проблем) внимает всем пожеланиям пользователей и расширяет свою функциональность, так сказать, по ходу дела. И здесь с одной стороны никому не интересны капризы верстальщиков, у которых на глазах разваливается продуманная для первой версии проекта модель - нужно быстрее, нужно сразу, нужно бежать, бежать в два раза быстрее хотя бы для того, что бы остаться на рынке. Здесь единственное разумное решение - дождаться того, что на каком-то этапе гонка закончится хотя бы незначительной паузой и руководство выделит человеко-часы на редизайн и ревёрстку всего проекта с нуля.
По второму пункту - да, вот прямо сейчас именно этим мы и занялись по одному из наших сервисов. Который начинался с двух простеньких контролов, работающих с простенькой базой данных. Там тоже была головная боль с тем, что заказчик точно не знал, чего же ему на самом деле хочется, но получив ту самую базовую функциональность, начал хотеть всё больше и больше, а сделать это было реально, добавлялись разделы, тулзовые панели, отчёты и фильтры, многопользовательский доступ и прочие пряники. Изначальная вёрстка, такая стерильная, логичная, семантичная, была забыта усложнившейся нереально модульной сеткой, таблица стилей выросла до кучи файлов с кучей же избыточных описаний и кривых наследований, но скоро, уже скоро всё изменится. Проект почти год крутился у клиента в том самом, более-менее законченном состоянии, работающий и внешне опрятный, но на вёрстку и стили я без содрогания смотреть уже не могла. И вот клиент созрел на полный редизайн, функциональность, кажется, меняться, во всяком случае принципиально и в ближайшее время не будет. Сделаем конфетку 
Так что по поводу холиворов на тему табличной и дивной вёрстки - да, мы ищем лёгих путей и как только у нас начинается очередное “стремительное развитие”, идём на компромиссы, таблицы используем и для каркасов и для оформления сложных форм, на более-менее предсказуемых же макетах в табличной вёрстке просто нет необходимости. Когда мы верстаем сайты, которые без дотнетовских движков, безтабличной вёрсткой ещё можно похвастаться, но как только речь заходит о дотнетовских проектах, то вопрос становится неактуальным, потому что кто в теме, тот и без меня знает, что такое дотнетовские контролы типа гридов или листвьювов, календарей или прочих “продвинутых” решений и во что они рендерятся в браузере. Ага, правильно! Таблицы в таблицах в таблицах. Т.е. полюбому приходится в таблицах стилей описывать элементы модульной сетки, построенные на табличной вёрстке. Это реальность, от которой никуда не денешься, разве только что если сменить компанию, где в качестве базовой технологии разработки используется что-нибудь другое.
Ну и на последок - примеры-частности. Ага, визуальные редакторы контента веб-страниц. Сделали замечательный такой сервис для мини-социальной сети (там закрытая группа, мало кому будет интересно), отличненько. По ТЗ мы делаем только каркас (топ, навигация, панель с тулзами), а содержание информационных страниц создают редакторы сервиса. Поставили им для начала простенький редактор - цвет текста поменять, картинку вставить, абзацы-ссылки-списки, конечно же, режим редактирования без визуальных средств чистый html, что людям нужно ещё для полного счастья? Им нужен продвинутый визуальный редактор типа как у word`а! Некоторое время пробовали уговорить, объясняли, какой бардак сейчас начнётся, не объяснили. Они захотели вот этот со всеми включенными тулбарами.
Разумеется уже через неделю раздались крики по поводу того, что у них на всех страницах (кроме главной), где они добавили своё содержание, разъехалось ВСЁ. Захожу в проект, смотрю, что они там намудрили, и не понимаю - зачем им весь этот расширенный тулбар, если они всё равно в визуальную зону вставляют форматированное нечто из того же word`а? Где у них образовалась таблица в таблице фиксированной ширины на 1500 пикселей и куча вторичного чиста word`овского кода в тегах? Предложили им простое решение - в контейнере, куда они грузят свой контент, добавить описание класса что-то типа overflow:auto;, не-а, говорят, не подходит. Не красиво. Полосы прокрутки не предусмотрены в концепте. Написали им документаху - чем можно пользоваться, чем нельзя и куда смотреть если что. Не помогло опять. Просто с какой-то периодичностью приходится заходить к ним с админскими правами и чистить тот код, который они очередной раз вставили в качестве обновлённого контента своих страниц.
Вот ещё замечательный пример: на ярушке один из верстальщиков глубокоуважаемого Яндекса Вадим Макишвили запостил провокационный пост про таблицы в макетах:
Не существует сейчас надежнее средства для создания сложной раскладки, чем таблица. Под надежностью я понимаю:
- уверенность в правильном поведении раскладки
- уверенность, что последующая модификация раскладки не принесет часов геморроя
- скорость разработки раскладки
Плюйтесь в меня желчью, фанаты семантики. Плюйтесь-плюйтесь… Когда вам доверят верстать портальные морды, которые обложены главным требованием — “ничего никогда не должно сломаться” — вернётесь к раскладе таблицами.
На сегодняшний день 139 комментариев, некоторые не безинтересно почитать; в частности, о резиновых каркасах, о различных ограничениях по ширине (Виталий Харисов: “В данном конкретном случае возможно. Не задавай max-width вообще. Если ты дебил и разворачиваешь окно браузера на максимум на 30″ мониторе, то тебе ничего не поможет.“) и о том, кто должен продумывать тот или иной тип макета и поведение блоков на странице.
Беги, Татьяна, беги [...] блог nundesign [...]
По поводу визуального редактора - большую часть вещей можно отфильтровать при хорошей конфигурации. Но от дурака не спасёт ничего
Они затребовали полноценный редактор, чтобы ничего не фильтровалось. Чтобы таблицы можно было создавать (а то, что там могут прописаться совершенно чудовищные размеры и прочие чудеса, уже как бы их проблема).
Я понимаю, но даже на полноценном редакторе можно гадость в коде фильтровать. Ну а размеры - дело модератора.
насчет дивной верстки в портальных мордах: Liferay Portal. ребята нарисовали портал с портлетами и очень красивую “дивную” тему. ничто никуда не разъезжатеся, ни в Опере, ни Лисе, ни в Осле, ни даже в Сафари. может быть все-таки дело в руках? или в лени? или и в том, и в другом?
насчет эволюционного прототипирования: дык Agile, однако. так теперь часто, если не сказать почти всегда. только ПМы от Agile, не всгда профи. очень хочется красиво выглядеть и тогда разработку “мы вот тут чуть-чуть подправим, вот тут слегка подмажем, здесь пару бажков пофиксим, а вот тут добавим функционала и успеем в срок, а сроку у нас на все неделя” называют красиво Agile. а с другой стороны именно Agile требует профессионализма и ПМа, и аналитика, и всей команды. Waterfall АКА Cascade как-раз прощает промашки в начальных сроках, с аналитикой вообще проблем нет, и команда может подтянуться до нужного уровня в процессе Elaboration. а в Agile нужно садиться и “давать стране метал”.
и про компоненты — не только в .Net. везде, причем как правило по итогу выгребать приходится гораздо больше проблем именно с табличной версткой компонента, когда нужно его красиво оформить или еще что-то с ним сделать. но зато, при разработке таблицой быстрее. альтернатива есть — писать сайт руками, контролы делать на HTML + JS. а это значит +2 человека в команду. но это не оправданный оптимизм, в реальности +4 разработчика и +2 тестера. вариант реальный только если заказчик маньяк валидной верстки (что само по себе плохо, я предпочтиаю заказчика, который фанат успешного бизнеса, тогда проблем с переговорами и взглядом на концепцию меньше, а пользы больше — платит регулярно, нацелен на результат и не лезет “учить жить”). так что врядли найдется контора, которая в качестве технологии разработки использует не компонентную модель, разве что вэб-студия. с другой стороны компоненты тоже на месте не стоят, я надеюсь что скоро и они будут рендерить нормальный HTML, тем более что это совсем не сложно.
н-да, про Liferay — насчет Оперы я погорячился
на самом деле у них другая тема была, в Опере работала нормально. тем не менее, продолжаю считать, что при должном уровне усердия и профессионализма — дивная верстка не проблема.
Ах, Антон. Да не проблема же конечно же. Если есть макет, который можно проанализировать на предмет разметки главных контейнеров и элементов и написать красивую таблицу стилей. Я же пишу не о том, что вот у нас была дивная вёрстка, а потом Agile режим нас замордовал и случилась табличная вёрстка, нет. Просто стерильная и логичная вёрстка стала не стерильной и не логичной, в таблицах стилей - куча избыточностей и неправильно объявленных наследований и всякое такое, и вот здесь по-хорошему нужно получить человеко-часы на то, чтобы спустя, скажем, несколько месяцев получить человеко-часы на работу, сесть, заново переосмыслить макет, переверстать шаблоны, переписать стили.
Потому что концепция изменилась, а стили - только правились и дописывались.
Редко когда бывает (хотя бывает,да), когда изначально внедрённый макет остаётся таким же, и при этом вполне гибким и спустя несколько месяцев разработки. Т.е. все нарасщиваемые страницы, и все затребованные элементы оформления - они там вполне добротно ложатся на уже спроектированный шаблон.
да я ведь не к тому, что Agile замордовал. просто так бывает. Waterfall проще и более прогнозируем для подрядчика, для заказчика немножко нервно заплатить за N-человекочасов, и получить результат только через это самое N часов / M человек. а вдруг не выгорит? потому и Agile. а где Agile, там и ваши проблемы. они на самом деле не только ваши, они общие. и тут я не случайно говорил про профессиональных ПМов. задача ПМа в Agile уметь грамотно обосновать для заказчика, когда пришло время рефакторинга. а оно приходит всегда. ибо эволюционное прототипирование. и это как-раз ваш случай, когда нужно время на рефактринг верстки и стилистики макета. я не прав?
а остальное, это скорее ответ на цитату. сорри, занесло
Татьяна, если честно, я не вижу логики. Ведь именно бестабличный макет легче всего видоизменять, чем табличный, в котором жестко задана та же модульная сетка.
По поводу визивигов. Я когда-то тоже любил давать клиенту полную свободу. Теперь же я ее обрубаю по самое не балуй, только основные необходимые контролы оставляю в редакторе.
Паш, я, кажется, знаю, почему не видишь логики. Ты как много верстал макеты для дотнетовских проектов? Если много, то все ли стандартные контролы ваши программеры писали с нуля сами, или же брали уже готовые гриды (таблицы с “расширенной функционаьностью”), деревья и прочие?
А про редактор. Я же ж говорю - такое было требование заказчика. Сначала спорили, обосновывали свою точку зрения, потом махнули рукой. Саппорт-то всё равно на нас остался
а это деньги. Поэтому поправить очередной “шедевр” форматирования ихней секретарши - не проблема.
Впрочем это именно тот проект, который пришёл к нам на редизайн. Может, мы пересмотрим вопрос с этим визуальным редактором.
эээ… ни одного для дотнета =)
…а потом смотришь на страницу, в код которой заглядывать уже страшно, с такой гордостью. Просто потому, что через год, после неоднократной смены смены всего и вся у ей внутре, она не разваливается.
Семантика ради самой семантики - да, не нужно по большому счету. Если на эту страницу никогда и ни при каких условиях не зайдет слепой, какая разница, как она читается? Но если сайт сделан специально для них? Или хотя бы в частности!
А провокация… Вот честно… Не люблю табличные макеты. Мне очень трудно отлавливать в них баги при изменении сетки. У меня начинается нервный тик при виде colspan’ов и необходимости “вот тут колонку добавить, а тут убрать”.
Готовые контролы с точки зрения верстальщика - зло
Но ситуация может поменяться на контрол “своими силами” только тогда, когда он станет злом и для программистов. По описанию функциональности .NET решений, вам это не грозит…
Прочитал - аж прослезился, насколько же до боли знакомо. Верстаем одно, потом в процессе хаки (и не только CSS) под контент. На самом деле спасибо за откровенность.
Офисное дизайнерское: склоки и подставы
[...] на вёрстку присылаются сюда, на Украину. Про различные недоговорённости и проблемы с вёрсткой я уже писала неоднократно, но сейчас разговор именно о [...]