HTML предлагает очень удобный аварийный выход, который позволяет веб-разработчикам добавлять семантическое значение элементам – атрибут class. Этот атрибут позволяет нам отметить некоторые экземпляры элемента как относящиеся к особенному классу или типы этого элемента. То, что браузеры не понимают того словаря, который мы используем в своих атрибутах class, не влияет на отображение наших документов.

Если в этом месте вы думаете: «Погодите-ка, разве классы нужны не для CSS?», вы отчасти правы. CSS-селекторы по классам – один из примеров технологии, которая использует атрибут class, но это не единственная причина использовать классы. Классы могут использоваться при написании скриптов для DOM и даже могут использоваться браузерами, если названия классов следуют заранее согласованным правилам, как это происходит в случае микроформатов.

Микроформаты – набор договоренностей, согласованных внутри сообщества. Эти форматы используют атрибут classдля того, чтобы заделать самые зияющие дыры в HTML: hCard – для контактов, hCalendar– для событий, hAtom– для новостных репортажей. Поскольку внутри сообщества существует договоренность о том, какие имена классов следует использовать, существуют парсеры и расширения браузеров, которые работают именно с этими шаблонами.

Микроформаты ограничены по самой своей задумке. Они не пытаются предложить решение для любого возможного сценария использования. Напротив, они нацеливаются на тот плод, что низко висит. Они предлагают решения для 80% сценариев использования, при этом на их создание затрачивается всего 20% усилий. Решить, что считается «плодом, что низко висит», довольно просто: нужно просто посмотреть на содержимое, которое люди уже размечают. Другими словами, заасфальтировать тропинки.

Звучит знакомо? Микроформаты и HTML5 построены на одной философии. По сути, то, как я описал микроформаты – договоренности, согласованные сообществом, – вполне применимо и к HTML5.

То, что микроформаты использовались в качестве модели для разработки HTML5, приходится не всем по вкусу. Хотя правило 80/20 достаточно хорошо работает для сермяжного мира наименований классов, действительно ли оно достаточно хорошо для самого важного языка разметки в мире?

Некоторые считают, что HTML должен быть бесконечно расширяемым. Это значит, что давать решения для большинства случаев недостаточно: язык должен предоставлять решения для любого возможного сценария.

Пожалуй, самый красноречивый аргумент такого типа привел Джон Олсоп (John Allsopp) в своей великолепной статье на A List Apart, «Семантика в HTML5» ( http://bkaprt.com/html5/6) [11]:

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

Уже существуют технологии для того, чтобы делать именно это. RDFa позволяют авторам встраивать в HTML-документы собственные словари. Но в отличие от микроформатов – которые просто используют заранее оговоренный набор наименований классов, – RDFa использует пространства имен для бесконечного разнообразия форматов. Так, там, где микроформат будет использовать примерно такую разметку:

, RDFa будет использовать:

Нет никакого сомнения в том, что RDFa – потенциально очень мощный инструмент, но его выразительность имеет свою цену. Пространства имен вводит дополнительный уровень сложности, который не очень согласуется с относительно простой природой HTML.

Спор о пространствах имен не нов. В записи в своем блоге несколько лет назад Марк Ноттингем (Mark Nottingham) размышлял о потенциально деструктивных побочных эффектах ( http://bkaprt.com/html5/7) [12]:

Что мне представляется интересным относительно расширяемости HTML – то, что пространства имен были необязательными: Netscape добавила blink, MSFT – marquee и т. п. Я бы сказал, что если бы в HTML с самого начала были пространства имен, это имело бы следующий эффект: вместо того чтобы (в конце концов) сойтись на одном и том же решении, различия между разными браузерами были бы легитимизированы и окончательно закреплены.

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

Скорее всего, HTML5 будет выпущен с каким-либо методом расширения его встроенной семантики. Конечно, атрибут class все еще на месте, поэтому микроформаты будут работать так, как работали. Возможно, HTML5 изменится, чтобы стать совместимым с RDFa, или, возможно, он будет использовать свой собственный словарь «микроданных».

В любом случае такая расширяемость, скорее всего, мало будет интересовать большинство веб-разработчиков. Что действительно имеет значение – это встроенная семантика, относительно которой существует согласие в сообществе и которая реализована производителями браузеров.

HTML5 вводит несколько новых строчных элементов, чтобы расширить наш существующий арсенал, состоящий из span, strong, em, abbrи других. Ах да, больше мы не называем такие элементы «строчными» – теперь они описывают «семантику на уровне текста».

Когда вы пролистываете список результатов поиска, вы заметите, что зачастую поисковый запрос подсвечен внутри каждого из результатов поиска. Вы можете разметить каждое вхождение поискового запроса элементом span, но span– костыль, не имеющий никакого семантического значения и годящийся мало на что, кроме как предоставлять место, куда можно было бы сунуть классы для применения стилей.

Можно использовать emили strong, но это не будет семантически верным; вы не хотите придавать особую важность запросу поиска, просто хотите, чтобы он был как-то выделен.

На сцену выходит элемент mark:

Результаты поиска по запросу 'единорог'

1. 



   Едем на единорогеюзабилити по радуге веба.

Элемент markне придает значения содержимому внутри него, а только показывает, что в данный момент он представляет интерес. Как говорит спецификация, markозначает «отрезок текста в одном документе, отмеченный или подсвеченный для справочных целей в связи с его релевантностью в другом контексте».

Элемент markразрешается использовать и в других контекстах, кроме как в результатах поиска, но, убейте меня, я не могу придумать ни одного такого примера.

hCalendar – один из самых популярных микроформатов, потому что он удовлетворяет общую для многих потребность: размечать события так, чтобы пользователи могли добавлять их напрямую в свой календарь.