Семантика в HTML5
Оригинал: http://www.alistapart.com/articles/semanticsinhtml5/
Иллюстрации: Кевин Корнелл
Перевод: Влад Мержевич
Я хочу сделать смелый прогноз. После того как вы и я исчезнем, HTML по-прежнему будет вокруг. Не только в миллиардах архивных страницах нашей эры, но, как живой, дышащий организм. Слишком много сил, энергии и инвестиций пошли в разработку инструментов Интернета, протоколов и платформ для того, чтобы от этого так легко отказаться.
Давайте остановимся на нашей ответственности. К сожалению, в истории мы связаны с развитием важного инструмента нашей цивилизации, который будет использоваться для коммуникации на десятилетия вперед. Таким образом, когда мы направляем наш разум, праздно или всерьез, на улучшение HTML, мы должны понимать уже сегодня последствия далеко идущих решений.
HTML5, над которым W3C недавно удвоил свои усилия по формированию следующего поколения HTML, развил значительный импульс. Это огромный проект, охватывающий не только структуру HTML, но и модель парсинга, обработку ошибок, DOM, алгоритмы извлечения ресурсов, медиа-контент, двумерную графику, шаблоны данных, безопасность, страницы загрузки, хранение данных на стороне клиента и многое другое.
Есть также изменения в структуре, синтаксисе и семантике HTML, которые частично описал Лаклан Хант в статье Предварительный обзор HTML 5.
Но в этой статье давайте обратимся исключительно к семантике HTML. Она интересует меня уже много лет и считаю, что семантика принципиально важна для будущего HTML.
Би-би-си недавно объявила, что отказывается от микроформата hCalendar используемого в их списках передач в пользу удобного и доступного шаблона сокращений. Это свидетельствует о том, что мы, вне всякого сомнения, вышли за пределы семантических возможностей HTML, которые были предназначены для этого языка. У нас просто закончились элементы и атрибуты HTML, которые обогащают семантическую разметку документов. Если мы продолжим хитрить с существующими конструкциями HTML, возникнет много проблем, потому что HTML как семантический язык разметки страдает от фундаментального дефекта — его семантика фиксирована и не расширяема.
Это не просто теоретическая проблема. Сотни тысяч разработчиков используют атрибуты class и id для создания расширенной семантической разметки. При этом практически неизменно разработчики используют специальные словари, которые они сами же составляют, а не значения, взятые из существующих схем. В лучшем случае это псевдосемантика.
Многие страницы в Интернете используют микроформаты, чтобы добавить больше структурированной семантики, чем имеющийся бедный набор HTML-элементов и атрибутов. В этом случае, значения, используемые для атрибута class, устанавливаются из согласованных словарей, иногда взятых из других стандартов, таких как vCard, а иногда из новоиспеченных словарей, где нет твердого стандарта (как в hReview).
Расширяемая семантика
Существует реальная проблема, которая должна быть решена. Нам нужны механизмы в HTML, которые чётко и однозначно позволят разработчикам добавлять в разметку более существенную семантику, а не псевдосемантику. Это, пожалуй, одна из важных целей проекта HTML5.
Но придумать такой механизм не так просто, потому что в любом решении имеются ограничения. Есть существенные ограничения, возможно, самым большим из них является обратная совместимость. Решение не должно ломать сотни миллионов используемых сегодня устройств, и которые будут использоваться ещё долгие годы. Любое решение без обратной совместимости не будет широко принято разработчиками из страха потерять читателей. Такие решения быстро вянут на корню.
Решение также должно быть совместимо и с будущими версиями. Не в том смысле, что оно должно работать в будущих браузерах — это ответственность разработчиков браузеров, но оно должно быть расширяемым. Мы не можем ожидать какого-либо единого решения, которое разрабатывается прямо сейчас, чтобы решить все мыслимые и немыслимые будущие семантические потребности. Мы можем разработать решение, которое удовлетворит расширяющиеся потребности по мере их возникновения.
Этот тандем двух ограничений является настоящей огромной проблемой. Но в контексте языка, основные итерации которого повторяются десятилетиями и важность которого в качестве глобальной платформы для коммуникации имеет первостепенное значение, эта задача должна быть решена.
Итак, как HTML5 решет этот вопрос? HTML5 вводит ряд новых элементов, некоторые из них я назвал «структурными» — <section>, <nav>, <aside>, <header> и <footer>. Элемент <dialog> по типу содержимого похож на <blockquote>. Есть также ряд элементов данных, таких как <meter>, который «представляет скалярное измерение в известном диапазоне или дробное значение, например, используемый объем диска» и элемент <time>, который указывает дату и/или время.
Хотя эти элементы могут быть полезными и, похоже, вызвали некоторый интерес, решают ли они действительно проблему, в частности обратной совместимости и совместимостью с будущими версиями?
Давайте рассмотрим каждое ограничение.
Обратная совместимость
Как современные браузеры обрабатывают новые элементы вроде <section>? Ну, самые последние версии Safari, Opera, Mozilla и даже IE7 будут отображать все страницы так.
<h1>Заголовок верхнего уровня</h1>
<section>
<h1>Заголовок второго уровня</h1>
<p>это текст внутри section</p>
<section>
<h1>Заголовок третьего уровня</h1>
</section>
</section>Похоже, отличное начало. Но когда мы пытаемся установить, к примеру, такой стиль для элемента <section>:
section {color: red}...большинство упомянутых браузеров изменило стиль элемента, но IE8 (а также IE6–7) нет.
Итак, мы имеем серьёзную проблему обратной совместимости с 75% используемых в настоящее время браузеров. Учитывая период полураспада Internet Explorer, мы можем предсказать, что большинство пользователей будут использовать IE6 и IE7 даже спустя несколько лет.
Если HTML5 вводит новые элементы, какова вероятность того, что они будут применяться большинством разработчиков с учетом того, что они по существу несовместимы с большинством браузеров? К сожалению, если вы увидите альтернативное решение проблемы CSS в том, чтобы включить атрибут class в элемент <section>, а затем попробовать изменить стиль с помощью класса, то это не будет работать в IE. Возможно, есть обходной путь, но если нет, на этом все дела заканчиваются.
Давайте обратимся ко второму ограничению — совместимость с будущими версиями.
Совместимость с будущими версиями
Начнём с постановки вопроса: «Зачем изобретать новые элементы?». Разумным ответ на него будет: «Потому что в HTML не хватает семантического богатства, а добавив эти элементы, мы увеличиваем семантическое богатство HTML — что не плохо, не так ли?».
При добавлении этих элементов мы стремимся, чтобы в HTML было больше семантических возможностей, но только в узкой области. Независимо от того, сколько элементов введено, мы всегда будем думать о добавлении в HTML больше семантики. Добавив столько новых элементов, сколько нам хочется, мы по-прежнему не решим проблему. Нам не нужно добавлять определенные термины в словарь HTML, нам необходимо добавить механизм, который позволит обогащать документ семантикой по мере необходимости. С технической точки зрения мы должны сделать HTML расширяемым. В HTML5 никакого механизма для расширения нет. Именно поэтому HTML5 угробит значительный процент современных браузеров и в реальности не добавляет семантику вообще.
Почему бы не принять существующий словарь, тот же Docbook? Его словарь структуры документа гораздо богаче и он разрабатывался рядом экспертов в течение многих лет. Однако это не является аргументом в пользу Docbook, дело в том, что задача обеспечения механизма семантического богатства в HTML идёт своим путём, уделяя мало внимания передовой практике в отношении работ тридцатилетней давности (исходная работа началась в начале 70-х годов).
Некоторые соображения по поводу решения
Критикуя нынешние усилия, есть ли у меня какие-то практические советы о том, как решить эту проблему? Ну, начну с одного.
Если добавление элементов в HTML находится за рамками темы, по крайней мере, в этой дискуссии, атрибуты это другая логическая область HTML, на которой мы сосредоточимся. В конце концов, в течение почти десятилетия мы использовали атрибуты class и id в качестве механизмов расширения семантики HTML. Множество разработчиков знакомы с этим подходом, и он их устраивает. Проект микроформатов показал, что существующих атрибутов HTML недостаточно для универсального механизма по расширению семантики HTML. Таким образом, если мы хотим использовать атрибуты чтобы помочь решить эту проблему, мы должны включить один или несколько новых атрибутов. Прежде чем перейти к механизму о том, как это работает, проверим это решение на те же требования, что и для новых элементов HTML5. Самое главное, поддерживают ли новые атрибуты HTML обратную совместимость? И если да, обеспечит ли это реальный механизм для семантического расширения HTML?
Давайте внедрим новый атрибут. Я назову его «structure», но конкретное имя не имеет значения. Мы можем использовать его так:
<div structure="header">Посмотрим, как наши браузеры справятся с ним. И конечно все браузеры должны изменить его стиль через CSS.
div {color: red}Но как это сделать?
div[structure] {font-weight: bold}В действительности, почти все браузеры, включая IE7, стилизуют <div> с атрибутом structure, даже если такого атрибута не существует! К сожалению, наше счастье на этом заканчивается, т.к. IE6 этого не делает. Но мы можем использовать атрибут в HTML, и все существующие браузеры признают его. Мы даже можем использовать CSS для стилизации нашего HTML с помощью атрибута во всех современных браузерах. И если мы хотим обойти старые браузеры, мы можем добавить к элементу значение класса для управления его стилем. Сравните это с решением в HTML5, который добавляет новые элементы, и которые не могут быть стилизованы в Internet Explorer 6 или 7 и вы увидите, что это решение, определенно, обратно совместимо лучше.
Расширяемость с помощью атрибутов
Вместо новых элементов, HTML5 должен принять ряд новых атрибутов. Каждый из этих атрибутов будет входить в категорию или тип семантики. Например, как я подробно изложил в другой статье, HTML включает структурную семантику, риторическую семантику, ролевую семантику (взята из XHTML) и другие классы или категории семантики. Эти новые атрибуты могут быть использованы так же, как атрибут class: для подключения к элементу семантики, которая описывает характер элемента, а также для добавления метаданных об элементе.
Это не отличается от атрибута role в XHTML, но вместо того, чтобы один атрибут «отдувался» за все семантические элементы, мы должны определить различные типы семантики элемента и разделить их. Например, атрибут role в XHTML работает следующим образом:
<ul role="navigation sitemap">
<li href="downloads">Скачать</li>
<li href="docs">Документация</li>
<li href="news">Новости</li>
</ul>Значения атрибута role это разделенный пробелами список слов из словаря по умолчанию или из определенного словаря.
Почему бы просто не взять атрибут role как есть? Ну, есть другие виды семантики, для которых словарь ролей неприменим. Например:
<p rhetoric="irony">Он фантастический человек.</p>Здесь показан теоретический тип семантики — «rhetoric», который может быть использован для разметки риторического характера документа. Этот элемент, очевидно, не играет роли иронии в документе. Скорее, содержит элемент иронии.
Вот еще один пример. Очевидно, что в HTML не хватает способа прикрепить версии для машинного чтения к версии для чтения человеком, например, дате. Это лежит в основе проблемы Би-би-си с микроформатом hCalendar, о которой мы говорили ранее. Хотя <span role="2009-05-01">Первого мая следующего года</span> действительно не несёт смысла, нечто вроде строки <span equivalent="2009-05-01">Первого мая следующего года</span> появится.
Опять же, будем ли мы использовать определенный термин «equivalent» или какой-либо другой термин для этого семантического атрибута не важно. Главное отметить, что это не так просто, как использование одного атрибута class или role на все случаи. Для правильного расширяемого решения, которое обеспечивает обратную совместимость и достаточную гибкость, решения в этом направлении заслуживают изучения. Я назвал этот раздел «Некоторые соображения по поводу решения», поскольку нужно сделать значительный объем работы, чтобы действительно добиться приемлемого решения. Открытые вопросы включают следующее.
- Сколько разных семантических атрибутов должно быть? Расширяются ли категории и если да, то как?
- Как определяются словари?
- Мы просто изобретаем желаемые термины подобно тому, как используется атрибут class или возможные значения должны определяться стандартной спецификацией? Или должен быть механизм для внедрения (и надеюсь обмена) словарями с помощью какого-то профиля?
- Если возникает конфликт между двумя словарями вроде двух одинаковых терминов в разных словарях, как он разрешается?
- Требуется ли пространство имён или другой подобный механизм?
Вместо того чтобы спешить ответить на эти вопросы, я выделю проблемы, которые необходимо решить и начну диалог. Последствия и влияние решений сделанных в HTML5 слишком велики для решений, которые будут сделаны без хорошей осведомлённости о лингвистике, семантике, семиотики и смежных областях. Надеюсь понятно, что просто «создание новых элементов» не является решением для роста семантической мощи HTML. Давайте несколько не будем спешить с этими решениями, в конце концов, изменением климата мы озаботили наших внуков достаточными проблемами. Пусть, по крайней мере, мы оставим им наилучший HTML какой сможем.