Нет никакого сомнения в том, что RDFa – потенциально очень мощный инструмент, но его выразительность имеет свою цену. Пространства имен вводит дополнительный уровень сложности, который не очень согласуется с относительно простой природой HTML.
Спор о пространствах имен не нов. В записи в своем блоге несколько лет назад Марк Ноттингем (Mark Nottingham) размышлял о потенциально деструктивных побочных эффектах [12]:
Помимо даже темы бесконечной расширяемости, это сильный аргумент за ограниченный словарь, построенный на согласии сообщества.
Скорее всего, HTML5 будет выпущен с каким-либо методом расширения его встроенной семантики. Конечно, атрибут class все еще на месте, поэтому микроформаты будут работать так, как работали. Возможно, HTML5 изменится, чтобы стать совместимым с RDFa, или, возможно, он будет использовать свой собственный словарь «микроданных».
В любом случае такая расширяемость, скорее всего, мало будет интересовать большинство веб-разработчиков. Что действительно имеет значение – это встроенная семантика, относительно которой существует согласие в сообществе и которая реализована производителями браузеров.
Новые элементы
HTML5 вводит несколько новых строчных элементов, чтобы расширить наш существующий арсенал, состоящий из span
, strong
, em
, abbr
и других. Ах да, больше мы не называем такие элементы «строчными» – теперь они описывают «семантику на уровне текста».
mark
Когда вы пролистываете список результатов поиска, вы заметите, что зачастую поисковый запрос подсвечен внутри каждого из результатов поиска. Вы можете разметить каждое вхождение поискового запроса элементом span
, но span
– костыль, не имеющий никакого семантического значения и годящийся мало на что, кроме как предоставлять место, куда можно было бы сунуть классы для применения стилей.
Можно использовать em
или strong
, но это не будет семантически верным; вы не хотите придавать особую важность запросу поиска, просто хотите, чтобы он был как-то выделен.
На сцену выходит элемент mark
:
h1Результаты поиска по запросу 'единорог'/h1
ol
lia href="http://clearleft.com/"
Едем на markединороге/mark юзабилити
по радуге веба.
/a/li
/ol
Элемент mark
не придает значения содержимому внутри него, а только показывает, что в данный момент он представляет интерес. Как говорит спецификация, mark
означает «отрезок текста в одном документе, отмеченный или подсвеченный для справочных целей в связи с его релевантностью в другом контексте».
Элемент mark
разрешается использовать и в других контекстах, кроме как в результатах поиска, но, убейте меня, я не могу придумать ни одного такого примера.
time
hCalendar – один из самых популярных микроформатов, потому что он удовлетворяет общую для многих потребность: размечать события так, чтобы пользователи могли добавлять их напрямую в свой календарь.
Единственная сложная часть в hCalendar – описывать дату и время так, чтобы компьютер мог их прочитать. Люди любят описывать даты: «25 мая» или: «в следующую среду», но парсеры хотят видеть красиво отформатированную по ISO дату: YYYY-MM-DDThh: mm: ss.
Сообщество по микроформатам придумало несколько умных решений этой проблемы, например использование элемента abbr
:
abbr class="dtstart" title="1992-01-12"
12 января 1992
/abbr
Если от того, что вы используете элемент abbr
таким образом, вас начинает немножко мутить, есть много других способов размечать машиночитаемые даты и время в микроформатах с помощью шаблона класс-значение. В HTML5 эта проблема разрешается новым элементом time
:
time class="dtstart" datetime="1992-01-12"
12 января, 1992
/time
Элемент time
может использоваться для обозначения даты, времени или того и другого вместе:
time datetime="17:00"17 часов/time
time datetime="2010-04-07"7 апреля/time