Веб-стандарты. Философия изящества. Часть 2

Артемий Ломов

Первую часть серии статей о философии веб-стандартов мы завершили перечислением трех китов, на которых зиждется красивая верстка. Теперь попробуем рассмотреть их поближе.

Четыре стихии

Чтобы говорить о разделении содержания, представления и поведения, нужно для начала прояснить, что это такое само по себе.

Содержание — это, грубо говоря, «полезный груз» веб-страницы, тот текст, который вы видите, разглядывая ее в окошке браузера.

Содержание документа обычно не отделимо или трудно отделимо от его структуры. Структура описывает разные смысловые единицы контента: заголовки, подзаголовки, абзацы текста, списки, определения, цитаты, смысловые выделения и прочее. Если речь идет об одной и той же статье, то заголовок останется заголовком, а абзац — абзацем в любых условиях. (Статья, разумеется, может быть отредактирована; ее структура при этом может претерпеть изменения; может измениться и само содержание — но мы сейчас тут обсуждаем не этот случай.)

Вот представление — уже гораздо более независимая от структурированного содержания категория. Говоря о представлении, мы имеем в виду особенности отображения или воспроизведения контента. Внешний вид веб-страницы на экране монитора настольного компьютера или ноутбука — это одно ее представление. Внешний вид той же самой страницы на маленьком экране мобильного устройства — это уже другое представление. Внешний вид веб-страницы, распечатанной на принтере — ее третье представление. Мы привели некоторые примеры визуальных представлений, а могут быть и другие их виды. Например, воспроизведение текста страницы речевым браузером или какой-либо другой программой синтеза речи относится к аудиальным представлениям этого документа. Незрячие люди пользуются для чтения текстов рельефной азбукой Брайля — так вот, если речь идет о выводе контента веб-страницы на механическую строку Брайля или о печати этого документа на специальном брайлевском принтере, подразумеваются тактильные представления. Ну и так далее.

Важно понимать, что структурированное содержание единственно, тогда как его представления множественны. Одна и та же веб-страница может выглядеть совершенно по-разному в различных условиях. Задача хорошего верстальщика — не препятствовать этой гибкости.

Поведение — это динамическое изменение содержания, структуры или представления веб-страницы в зависимости от действий пользователя или каких-либо других событий. Широкие возможности по управлению поведением, предоставляемые современными и перспективными веб-технологиями стороны клиента, позволяют создавать сложные интерактивные динамические приложения, работающие на локальной машине пользователя и бережно использующие ресурсы сервера, не плодя бесчисленные запросы к нему по любому пустяковому поводу.

Большая тройка технологий

Если говорить о конкретной реализации, то, применительно к большинству веб-страниц, для структурирования контента в современном мире используется HTML (и XHTML — что бы это ни значило — сюда тоже запишем), за управление представлением отвечает CSS, а задачи управления поведением возложены на JavaScript. Это лишь базовые общеупотребительные технологии — очередные три кита, если хотите. Вообще разнообразных технологий, ответственных в той или иной мере за очерченные сферы, конечно же, гораздо больше — но сей вопрос мы обсудим, пожалуй, не в этот раз.

По мере развития HTML, CSS и JavaScript наблюдается смещение границ их сфер влияния.

Лет 15 тому назад для того, чтобы сделать шрифт надписи покрупнее и покрасить буквы красным, любой веб-мастер написал бы прямо в HTML-коде вот что: <font size="+1" color="#ff0000">очень важная надпись</font>. И оказался бы совершенно прав, ибо других способов добиться желаемого не существовало в принципе. Сегодня же за такое сразу выдают чугунную медаль за профнепригодность.

Лет 10 тому назад реализация эффекта «перекатывания» кнопок меню навигации не обходилась без JavaScript. Спецификация CSS2 уже даже была рекомендацией W3C, но это мало кого трогало — в распространенных на тот момент браузерах она толком не работала.

Лет 5 тому назад такую штуку, как изменение расположения и нюансов внешнего вида блоков на странице в зависимости от ширины окна браузера, можно было сделать только при помощи JavaScript. Сегодня уже можно пользоваться для этих целей возможностями Media Queries — одного из модулей CSS3. Пока, правда, осторожненько так, но, думаю, в ближайшие пару лет во всех вменяемых браузерах будет реализована адекватная поддержка этого великолепия.

Семантика

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

На базовом уровне речь идет об использовании элементов HTML-разметки строго по их прямому назначению. К примеру, структурную единицу, по смыслу являющуюся заголовком первого уровня, необходимо размечать тегом <h1> и только им — другие элементы разметки для этого не подходят по своему назначению. Верно и обратное: использовать тег <h1> надлежит для разметки только и только такого элемента, смысловая роль которого — заголовок первого уровня. (Обычно заголовок первого уровня — это заглавие документа в целом, и такой элемент употребляется на странице в единственном экземпляре. Хотя спецификации HTML отнюдь не запрещают использование множественных элементов <h1> — ну, это к вопросу о духе и букве.)

Можно выделить и другие, более высокие уровни семантики. Следующий уровень — грамотное именование классов и идентификаторов элементов HTML-разметки. Названия этим классам и идентификаторам следует назначать в соответствии со смысловой нагрузкой соответствующих элементов. Широко распространенная в среде разработчиков практика отталкиваться в именовании классов и идентификаторов от особенностей визуального представления элементов, с точки зрения духа веб-стандартов, является глубоко ошибочной и порочной.

Приведу простой пример для наглядности. Предположим, дизайн некоторого сайта предполагает использование цветового выделения дат публикации свежих новостей в блоке с информацией о текущих обновлениях. Скажем, оранжевым. Казалось бы, ничто не мешает нам разметить соответствующие элементы примерно следующим образом: <span class="orange">07.06.2011</span>, определив стилевые правила для класса orange в CSS-коде. А теперь представьте, что спустя некоторое время нам захотелось модифицировать цветовую схему новостного блока — ну, допустим, изменить выделение дат публикации новостей с оранжевого на синее. Конечно, можно было бы оставить код разметки в покое, заменив только соответствующее стилевое правило, но в таком случае старое, неактуальное уже название класса станет противоречить здравому смыслу и вносить лишнюю путаницу в и без того трудную жизнь — по-хорошему, код разметки надо бы тоже поправить. А вот если бы мы сразу поименовали соответствующий класс в соответствии с его смысловой нагрузкой — ну, например, как-то вроде newsdate, — описываемой проблемы не возникло бы в принципе. Кстати, в HTML5 для разметки информации о дате и времени предусмотрен специальный элемент <time>. Так что, если вы используете в верстке сайта именно HTML5, то совсем правильным было бы применение для обсуждаемых целей вот этого самого элемента <time> вместо семантически нейтрального <span>.

Даже если в верстке вашего сайта применяются элементы с абсолютно одинаковым стилевым оформлением, но с различными смысловыми ролями — не используйте для них один и тот же класс! Ведь ситуация может измениться. Это вовсе не означает, что она обязательно изменится при жизни сайта, но категорически исключать такую возможность — по меньшей мере недальновидно.

На еще более высоком уровне семантики речь заходит о различных штуках, позволяющих наделять те или иные элементы какими-либо дополнительными метаданными (облегчающими возможную машинную обработку контента) уже сверх уровня обычной HTML-разметки. Примерами соответствующих технологий являются микроформаты, Microdata и RDFa.

Лично я, признаться честно, ленюсь использовать микроформаты и прочие подобные вещи, хотя временами по этому поводу испытываю угрызения совести. Отчасти успокаивает меня то, что в целом в среде веб-стандартистов нет однозначного мнения о том, что дополнительная семантика — это вот прямо такая позарез жизненно необходимая штука и вообще единственный путь ко спасению. Есть, чего уж там, и более насущные материи.

Валидность

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

В случае с веб-разработкой следование букве спецификаций веб-технологий убережет вас от потенциальных неприятных неожиданностей, связанных с вашими собственными ошибками. От неожиданностей, вызванных, предположим, ошибками реализации стандартов в браузерах — конечно, не убережет. Но, согласитесь, подкрепленная отчетом валидатора уверенность в том, что вы предусмотрели все возможное хотя бы только со своей стороны — это уже само по себе великое дело.

Формальное соответствие HTML- и CSS-кода веб-страниц спецификациям W3C можно, как известно, проверить онлайновыми валидаторами разметки и таблиц стилей на официальном сайте консорциума.

Если вы относительно консервативны и не выходите в процессе разработки за рамки спецификаций, уже официально утвержденных в качестве рекомендаций W3C (речь идет, например, о сочетании XHTML 1.0 Strict и CSS2.1), в идеале необходимо стремиться доводить код до полностью валидного состояния. Тут все, в общем-то, предельно ясно.

Менее однозначной ситуация представляется в том случае, если вы решились использовать перспективные технологии (скажем, элементы HTML5 и CSS3), не дожидаясь их утверждения в качестве рекомендаций. (Как уже отмечалось, это совершенно нормальная и, более того, заслуживающая всяческих похвал практика.)

Как тут поступить? В плане проверки валидности проблем почти нет — онлайновые валидаторы на сайте W3C уже давно научились понимать HTML5 (похоже, что даже в полной мере) и CSS3 (увы, здесь наблюдается ряд проблем, но баги отслеживаются и исправляются).

Препятствий для обеспечения абсолютной валидности кода разметки тоже никаких нет. «Фундамент» HTML5 — словарь и грамматика языка разметки — относительно небольшая часть всей спецификации, которая, надо надеяться, уже в деталях проработана и не будет в дальнейшем претерпевать принципиальных изменений.

CSS3 развивается несколькими десятками отдельных модулей, находящихся в разных стадиях проработки (так, CSS Color Module Level 3 уже получил, в один день со спецификацией CSS2.1, статус рекомендации). Особенность процесса развития CSS такова, что спецификация того или иного модуля CSS3 не имеет шансов на утверждение в качестве рекомендации в сколько-либо обозримые сроки до тех пор, пока не появится несколько полных не противоречащих друг другу реализаций данного конкретного модуля в основных браузерах. Потенциальной возможностью пересмотра тех или иных разделов «сырых» спецификаций порождена необходимость в первое время использовать экспериментальные свойства и значения CSS с вендорными префиксами — например, -moz- (для Mozilla Firefox), -webkit- (для браузеров на основе движка Webkit — в частности, Chrome и Safari), -o- (для Opera). Применение конструкций CSS, использующих вендорные префиксы, конечно же, с формальной точки зрения автоматически делает соответствующие таблицы стилей невалидными, но этот «костыль нового поколения» — во всех отношениях разумное и удачное решение, против которого ничего не имеют ни W3C, ни сообщество веб-стандартистов. (К слову, у упоминавшегося CSS-валидатора с сайта W3C даже есть опция проверки таблиц стилей с учетом использования вендорных префиксов.)

В среде веб-стандартистов сложилась практика стремиться достигать абсолютной валидности кода разметки, а к таблицам стилей относиться более либерально, ограничиваясь обеспечением их синтаксической корректности в свете имеющейся потребности в использовании вендорных префиксов. Есть и чисто идеологическое объяснение этому: валидность кода разметки куда как более важна, чем валидность таблиц стилей, ибо код разметки описывает самоценную сущность — структурированное содержание, а код таблиц стилей — всего лишь представление, которое не может существовать без содержания, и вариантов которого для одного и того же содержания теоретически может быть бесконечно много. (Для старых версий IE, пользуясь условными комментариями, веб-разработчики подключают таблицы стилей, содержащие порой та-а-акие хардкорные хаки — и ничего, живем… Нормальным браузерам и валидатору все, что скрыто за условными комментариями, безразлично. Ну да, конечно, это не верх изящества, а вполне себе костыль — но ничего лучше пока не придумали. Абсолютно валидные как в плане разметки, так и в плане стилей страницы, отображающиеся в IE6 не хуже, чем в остальных браузерах, возможны, но их внешний вид напомнит вам о начале века.)

Продолжение следует.