Семантика в HTML 5

Пока в HTML 5 есть две проблемы: отсутствие обратной совместимости, так как новые семантические элементы не будут работать в 75 процентах браузеров, и отсутствие совместимости с будущими версиями, поскольку семантические элементы не являются расширяемыми. Если изобретение новых элементов — не выход, то что же делать?

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

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

HTML 5, с удвоенной силой разрабатываемый W3C в качестве следующего поколения HTML, за последний год получил значительный импульс в развитии. Это огромный проект, касающийся не только структуры HTML, но также и моделей парсинга, обработки ошибок, DOM, алгоритмов выборки ресурсов, медиа-контента, 2D-рисования, создания шаблонов для данных, моделей безопасности, загрузки страниц, хранения данных на стороне клиента и так далее.

Это также и пересмотр структуры, синтаксиса и семантики HTML, о чём частично рассказал Лаклен Хант (Lachlan Hunt) в своём «Обзоре HTML 5».

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

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

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

Многие веб-страницы используют микроформаты для улучшения семантической структуры существующего набора HTML-элементов и атрибутов. В этом случае, значения атрибута class устанавливаются по заранее определённым соглашениям, иногда заимствованным из других стандартов, например vCard, либо, если признанных стандартов не существует, создаётся собственная терминология (как в случае с hReview).

Расширяемая семантика

Здесь мы сталкиваемся с существенными проблемами. Нам нужны такие средства HTML, которые позволили бы веб-разработчикам создавать чёткую, однозначную и более выразительную семантически разметку (и я говорю не о псевдосемантике). Это, возможно, наиболее важная задача, стоящая перед HTML 5.

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

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

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

Итак, что же нам предлагает HTML 5? В нём вводится несколько новых элементов. Некоторые из них являются «структурными»: section, nav, aside, header и footer. Элемент dialog — это содержательный элемент, похожий на blockquote. Также введены элементы данных, такие как meter, который «служит для представления чисел в определённом интервале или дробных значений, например, количества свободного места на диске», и time, который используется для указания даты и/или времени.

Эти элементы могут быть полезны и вызывают определённый интерес, но способны ли они решить описанную нами проблему, в частности, ограничения на обратную и будущую совместимость?

Давайте рассмотрим каждойе из ограничений.

Обратная совместимость

Как браузеры обрабатывают новые элементы, например section? Что ж, последние версии Safari, Opera, Mozilla и даже IE7 сгенерируют страницу правильно.

Заголовок первого уровня

Заголовок второго уровня

Текст в элементе section.

Заголовок третьего уровня

Начало замечательное. Но если мы попробуем применить стили к элементу section:

section {color: red}

… большинство из упомянутых браузеров справятся с задачей, а вот IE7 (и, соответственно, 6) — нет.

Таким образом, мы имеем серьёзные проблемы с совместимостью в 75% используемых в данный момент браузеров. Зная «период полураспада» браузера Internet Explorer, можно предположить, что многие будут пользоваться им ещё в течение нескольких лет.

Какова вероятность, что подавляющее большинство разработчиков станут использовать эти новые элементы HTML 5, зная что они несовместимы с большинством браузеров? (Примечание переводчика: не стоит быть столь категоричным в оценках, так как доля IE7 и IE6 не составляет большинство, и, к тому же, уменьшается с каждым месяцем.)

К сожалению, если вы попытаетесь решить проблему с CSS иным способом, например, присваиванием элементу section атрибута class и использованием его в таблице стилей, то снова потерпите неудачу в IE. Возможно, есть какой-то выход, но пока он не найден, это будет серьёзным препятствием.

Давайте рассмотрим следующее ограничение — будущую совместимость.

Будущая совместимость

Зададим себе такой вопрос: «Почему мы должны придумывать новые элементы?». Разумным ответом было бы: «Потому что в HTML бедная семантика, а добавляя эти элементы мы делаем её разнообразней — неплохо, не правда ли?».

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

Вместо этого, HTML 5 добавляет элементы, которые сейчас не работают во многих браузерах и в действительности не позволяют нам расширить семантику языка.

Относительно новых элементов остаются ещё некоторые вопросы. Откуда были взяты их имена? Как было принято решение о необходимости элемента навигации с именем «nav»? Почему один и тот же термин применяется к навигации как внутри страницы, так и по сайту, и даже между сайтами?

Почему бы не взять существующий словарь терминов, например Docbook? Его словарь намного более разнообразен, и разрабатывался специалистами в издательской деятельности на протяжении многи лет. Это не аргумент в поддержку Docbook, суть в том, что чрезвычайно важная задача создания семантических механизмов в HTML решается такими непродуманными методами, почти не учитывая накопленный за последние 30 лет опыт разработок в этой области. (Разработка GML началась в 1970-х годах.)

Мысли по поводу решения

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

Если добавление новых элементов не поможет делу, по крайней мере, в рамках нашей дискуссии, стоит обратить внимание на атрибуты HTML. В конце концов, мы уже лет десять используем class и id для расширения семантики HTML. Множество разработчиков знакомы с такой практикой и полностью удовлетворены ей. Проект microformats показал, что существующих атрибутов HTML в общем недостаточно для расширения семантики. Поэтому, если мы хотим решить проблему с помощью атрибутов, придётся использовать один или несколько новых атрибутов. Перед тем как понять, как это может работать, стоит подумать о уже упомянутых ограничениях. Главное — будут ли новые атрибуты обратно совместимы? И если да, то могут ли они предложить рабочий механизм для расширения семантики HTML?

Давайте придумаем новый атрибут. Я назову его «structure», хотя имя не так важно. Мы можем использовать такую конструкцию:

Посмотрим, как с этим справятся браузеры.

Конечно, во всех браузерах к этому элементу можно применить стили:

div {color: red}

Но как насчёт такого?

div[structure] {font-weight: bold}>

На самом деле, почти все браузеры, включая IE7, позволяют это сделать, даже если атрибута structure нет в HTML! К сожалению, затем удача нам изменяет — IE6 так не умеет. Тем не менее, мы можем использовать этот атрибут — все существующие браузеры его распознают, а все современные браузеры позволят добавлять для него стили. Если же необходимо обеспечить поддержку старых браузеров, в таблице стилей можно использовать атрибут class. Сравните это с решением, предлагаемым HTML 5, в котором к новым тегам невозможно применять стили в Internet Explorer 6 и 7. Теперь вы видите, что оно обратно совместимо в гораздо меньшей степени.

Расширяемость с помощью атрибутов

Вместо новых тегов, в HTML 5 должны быть введены новые атрибуты. Каждый из этих атрибутов будет относиться к определённой семантической категории. HTML, как я подробно рассказывал в другой статье, включает в себя структурную семантику, риторическую семантику, ролевую (как в XHTML) и другие.

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

Это весьма похоже на атрибут role в XHTML, однако вместо единой «связки» для всех семантических элементов, мы должны определить отдельные атрибуты применительно к каждой семантической категории.

К примеру, атрибут role в XHTML используется таким образом:

  • Загрузки
  • Документация
  • Новости

Значением атрибута role является список слов, разделённых пробелом, и взятых из стандартной или определённой пользователем терминологии.

Почему бы просто не позаимствовать атрибут role? Потому что существуют другие семантические категории, к которым нельзя применить описание роли, например:

Он замечательный человек.

Здесь использован теоретически возможный атрибут «rhetoric», который может быть использован для разметки риторического смысла документа. Очевидно, что элемент, к которому он применён, не играет роли «ирония», хотя его содержимое и является ироничным.

Вот другой пример. Совершенно очевидно, что в HTML не хватает способа привязки машино-читаемого описания к понятному человеку значению, например, к дате. Именно это послужило поводом к отказу BBC от микроформата hCalendar, о чём я уже говорил ранее. Следующий код:

Первое мая

не имеет смысла, но что-то вроде такого:

Первое мая

вполне применимо.

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

Я назвал этот подраздел «Мысли по поводу решения», поскольку впереди ещё огромное количество работы, и есть множество вопросов, остающихся открытыми:

— Сколько различных семантических атрибутов должно быть? Должны ли эти категории быть расширяемыми, и если да, то как?
— Как будут определяться словари терминов?
— Будем ли мы просто придумывать необходимые термины, как при использовании значений класса, или же возможные значения должны быть стандартизированы спецификацией? Должен ли существовать механизм добавления (и коллективного использования) пользовательских словарей, используя что-то вроде профилей?
— Если два словаря будут конфликтовать между собой, к примеру, при совпадении терминов, как может быть разрешена такая ситуация?
— Нужен ли нам механизм пространств имён, или нечто подобное?

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

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

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