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

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

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

Мысли, раскрываемые здесь, в тех или иных сочетаниях уже не раз озвучивались мной устно на различных семинарах и конференциях, но как-то до сих пор не представлялось повода объединить тезисы, посвященные каким-то частным проблемам, в целостный рассказ и облечь его в «твердую» письменную форму. Кое-что о философии веб-стандартов я, конечно, писал в своих колонках на «ИнфоБуме» и в первой книжке, но это было уже слишком давно. С тех пор мир существенно преобразился. Наверное, уже целое поколение веб-разработчиков успело смениться.:-)

Стандарты или рекомендации?

Начнем с того, что сам по себе термин «веб-стандарты» (калька с англоязычного “webstandards”), положа руку на сердце, не вполне корректен — ну или, по крайней мере, не вполне точен и самоочевиден. Под веб-стандартами в узком смысле понимаются спецификации, разрабатываемые консорциумом W3C — а документы эти имеют статус рекомендаций, то есть их можно придерживаться, а можно и нет — никто насильно не заставляет. Спецификации W3C (за исключением редких частных случаев) не обладают статусом стандартов ISO или ГОСТ. Их несоблюдение не может повлечь за собой какие бы то ни было санкции в отношении веб-разработчиков или производителей браузеров со стороны гипотетических контролирующих органов — штрафы, отзывы лицензий и прочее подобное. Собственно, в этом мне видится одна из причин, скажем прямо, наплевательского отношения к букве спецификаций W3C подавляющего большинства веб-разработчиков, не склонных страдать приступами перфекционизма.

И даже еще не рекомендации!

Скажем больше. Рекомендация — это финальный статус спецификации W3C. До момента утверждения в таком статусе разрабатываемая спецификация проходит «огни, воды и медные трубы» весьма многочисленных этапов «шлифовки». Процесс этот порой по разным причинам затягивается на много-много лет. Так, например, официального утверждения спецификации CSS2.1 в качестве рекомендации W3C прогрессивная общественность ждала почти 10 лет — и дождалась наконец-таки вот буквально на днях, 7 июня. В складывающихся условиях производители браузеров реализуют в своих продуктах, а веб-разработчики используют на создаваемых сайтах элементы «сырых» (то есть формально находящихся в разработке и ожидающих тех или иных дальнейших изменений) спецификаций задолго до их утверждения в качестве рекомендаций. Впрочем, только по такому сценарию и возможно вообще развитие веб-технологий как таковое — в этом процессе должно прямо или косвенно участвовать все профессиональное сообщество, а не только избранные участники рабочих групп W3C. Консорциум W3C, спору нет, — локомотив развития веб-стандартов, но, на минуточку, задача локомотива — тянуть за собой вагоны с пассажирами в нужном последним направлении. Локомотиву же, вообразившему себя самодостаточным, ничего не остается, как проследовать на тупиковый путь в полном одиночестве — что весьма наглядно продемонстрировала нам история XHTML2.

Открытость

Принципиально важный момент заключается в том, что веб-стандарты являются открытыми — любой желающий может совершенно свободно пользоваться этими технологиями, и они не защищены никакими патентами никаких компаний. Исторически так сложилось, что наряду с открытыми стандартами на веб-сайтах нашли себе применение и разного рода проприетарные технологии — скажем, графический формат GIF (срок его патентной защиты, правда, уже истек) или, например, Flash. Сообщество веб-стандартистов выражает уверенность в том, что рано или поздно таким вещам придется освободить занятое теплое место в пользу открытых стандартов (ну, предположим, формат GIF может быть замещен форматом PNG, а «убить» Flash и Silverlight вполне по силам таким технологиям, как SVG, Canvas и встроенная поддержка видео в HTML5 — на разных фронтах будут применяться различные тактики наступления.)

Чем плохи проприетарные технологии? Почему Flash и Silverlight обязательно нужно «убить»? Есть смысл остановиться на этом поподробнее, поскольку многие разработчики даже вполне прогрессивных взглядов недооценивают «масштаб бедствия».

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

Возможно, кто-то помнит, что в окрестностях 2004 года доля IE превышала 90%. И я лично знаком с людьми, которые тогда на полном серьезе предлагали объявить IE «единственно правильным» браузером, узаконить его монополию и развивать стандарты веб-технологий «от противного» — то есть руководствуясь тем, как реализована поддержка той или иной функциональности в IE. Сегодня подобные заявления кажутся нам горячечным бредом, но тогда у этой идеи были сторонники — причем, в общем-то, даже среди вполне адекватных во всех прочих воззрениях персоналий.

Нет необходимости фантазировать, что было бы (например, со всем зоопарком мобильных устройств, которые теперь, в отличие от 2004 года, поголовно умеют ходить в Интернет), если бы этот кошмарный сон волею какого-нибудь вопиющего массового помешательства смог стать реальностью. Достаточно вспомнить только тот реальный исторический факт, что IE7 вышел спустя пять с лишним лет (что в масштабах Интернета равносильно вечности) после выпуска IE6 — и то, надо полагать, это радостное событие изрядно поторопила нараставшая конкуренция со стороны Firefox, первая версия коего появилась на свет, на беду IE, в конце пресловутого 2004 года.

В общем, Интернет — это не корпоративная интрасеть частной лавочки. Проприетарным решениям и монополиям здесь не место.

Дух и буква

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

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

Вот такая же штука и с веб-стандартами. Можно сверстать страницу, которая будет проходить проверку валидатором на соответствие спецификации XHTML 1.0 Transitional, но при этом код не будет иметь ничего общего с версткой не то что хорошего, но даже минимально приемлемого уровня. (Впрочем, сказанное справедливо даже для XHTML 1.0 Strict и HTML5 — свободы там ощутимо меньше, но ее все равно более чем достаточно.Не применяйте тегов <h1>…<h6> для обособления заголовков; отделяйте абзацы текста друг от друга тегом <br>, не используя для этих целей элементы <p>; горизонтальные отступы создавайте при помощи последовательностей из множества неразрывных пробелов; вставляйте картинки, не являющиеся частью контента, а служащие декоративными элементами, всегда при помощи тега <img> вместо того, чтобы делать их фоновыми рисунками; старайтесь как можно чаще использовать inline-стили — и цель будет достигнута. Любой приверженец веб-стандартов с не слишком крепкими нервами упадет в обморок от вашего кода.)

С другой стороны, можно сверстать страницу относительно хорошо, с уважением к духу веб-стандартов, но забыть в спешке перед дедлайном вычистить пару ошибок валидации. Или даже допустить их намеренно. (Сегодня, в период, который увлеченные натуры называют эпохой Web 2.0, эта проблема особенно актуальна в связи с тем, что «автономные» сайты почти вымерли — все вокруг считают священным долгом понавешать себе на страницы всякие счетчики, виджеты социальных сетей, разнообразные информеры, рекламные блоки… И, мягко говоря, далеко не все эти произведения сторонних разработчиков идеальны. А перфекционистов, готовых пожертвовать каким-нибудь красивым виджетом в пользу абсолютного совершенства верстки, — единицы.)

Три кита

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

• разделение содержания, представления и поведения на уровне конечного кода веб-страниц, отправляемого сервером клиенту;
• семантичность разметки;
• валидность кода разметки и синтаксическая корректность кода таблиц стилей и скриптов клиентской стороны.

Часть 2

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

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

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

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

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

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

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

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

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

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

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

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

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

Семантика

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

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

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

Приведу простой пример для наглядности. Предположим, дизайн некоторого сайта предполагает использование цветового выделения дат публикации свежих новостей в блоке с информацией о текущих обновлениях. Скажем, оранжевым. Казалось бы, ничто не мешает нам разметить соответствующие элементы примерно следующим образом: <spanclass="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 ColorModuleLevel 3 уже получил, в один день со спецификацией CSS2.1, статус рекомендации). Особенность процесса развития CSS такова, что спецификация того или иного модуля CSS3 не имеет шансов на утверждение в качестве рекомендации в сколько-либо обозримые сроки до тех пор, пока не появится несколько полных не противоречащих друг другу реализаций данного конкретного модуля в основных браузерах. Потенциальной возможностью пересмотра тех или иных разделов «сырых» спецификаций порождена необходимость в первое время использовать экспериментальные свойства и значения CSS с вендорными префиксами — например, -moz- (для MozillaFirefox), -webkit- (для браузеров на основе движка Webkit — в частности, Chrome и Safari), -o- (для Opera). Применение конструкций CSS, использующих вендорные префиксы, конечно же, с формальной точки зрения автоматически делает соответствующие таблицы стилей невалидными, но этот «костыль нового поколения» — во всех отношениях разумное и удачное решение, против которого ничего не имеют ни W3C, ни сообщество веб-стандартистов. (К слову, у упоминавшегося CSS-валидатора с сайта W3C даже есть опция проверки таблиц стилей с учетом использования вендорных префиксов.)

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

Часть 3

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

Таких следствий очень много. Попытаемся перечислить и обосновать самые главные из них.