Прежде мы уже выделяли такие аспекты концепции современных веб-стандартов, как семантика и валидность. Теперь рассмотрим их предназначение подробнее.
Семантика
В верстке понятие семантичности разметки означает внимательное отношение к смысловой нагрузке тех или иных структурных единиц при написании кода. Существует несколько уровней использования семантики.
1) На базовом уровне речь идет об использовании элементов HTML-разметки строго по их прямому назначению.
К примеру, структурную единицу, по смыслу являющуюся заголовком первого уровня, необходимо размечать тегом <h1> и только им — другие элементы разметки для этого не подходят по своему назначению. Верно и обратное: использовать тег <h1> надлежит для разметки только и только такого элемента, смысловая роль которого — заголовок первого уровня.
Обычно заголовок первого уровня — это заглавие документа в целом, и такой элемент употребляется на странице в единственном экземпляре. Хотя спецификации HTML отнюдь не запрещают использование множественных элементов <h1> — ну, это к вопросу о духе и букве.
2) Следующий уровень — грамотное именование классов и идентификаторов элементов HTML-разметки. Названия этим классам и идентификаторам следует назначать в соответствии со смысловой нагрузкой соответствующих элементов. Широко распространенная в среде разработчиков практика отталкиваться в именовании классов и идентификаторов от особенностей визуального представления элементов, с точки зрения духа веб-стандартов, является глубоко ошибочной и порочной.
Предположим, дизайн некоторого сайта предполагает использование цветового выделения дат публикации свежих новостей в блоке с информацией о текущих обновлениях. Скажем, оранжевым. Казалось бы, ничто не мешает нам разметить соответствующие элементы примерно следующим образом: <spanclass="orange">07.06.2011</span>, определив стилевые правила для класса orange в CSS-коде. А теперь представьте, что спустя некоторое время нам захотелось модифицировать цветовую схему новостного блока — ну, допустим, изменить выделение дат публикации новостей с оранжевого на синее. Конечно, можно было бы оставить код разметки в покое, заменив только соответствующее стилевое правило, но в таком случае старое, неактуальное уже название класса станет противоречить здравому смыслу и вносить лишнюю путаницу — по-хорошему, код разметки тоже надо поправить. А вот если бы мы сразу поименовали соответствующий класс в соответствии с его смысловой нагрузкой — ну, например, как-то вроде newsdate, — описываемой проблемы не возникло бы в принципе.
Кстати, в HTML5 для разметки информации о дате и времени предусмотрен специальный элемент <time>. Так что, при использовании в верстке сайта именно HTML5, совсем правильным было бы применение для обсуждаемых целей вот этого самого элемента <time> вместо семантически нейтрального <span>.
Даже если в верстке сайта применяются элементы с абсолютно одинаковым стилевым оформлением, но с различными смысловыми ролями — не рекомендуется использовать для них один и тот же класс! Ведь ситуация может измениться. Это вовсе не означает, что она обязательно изменится при жизни сайта, но категорически исключать такую возможность — по меньшей мере, недальновидно.
3) На еще более высоком уровне семантики речь заходит о возможности наделять те или иные элементы какими-либо дополнительными метаданными, облегчающими возможную машинную обработку контента, уже сверх уровня обычной 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 не хуже, чем в остальных браузерах, возможны, но их внешний вид напомнит вам о начале века.
Ключевые концепции философии современных веб-стандартов важны не сами по себе, а исключительно благодаря тем положительным следствиям, которые порождают уважительное отношение к этим самым концепциям со стороны веб-разработчиков в повседневной практике.
