Искусство семантики HTML, часть 1

В 2014 году говоря о семантике в HTML, нельзя не отметить достижения в этой области.

Есть section, header, aside, footer, main и даже menu! У нас в распоряжении есть всё необходимое, верно? Тогда почему же мы продолжаем делать вот так?

<body class="article">
<div class="content">

Всякий раз, когда лень или нехватка времени вынуждали меня писать такие вещи, я чувствовал себя виноватым. И вот я решил освежить свои представления о том, как правильно использовать наши старые добрые стандарты разметки. С чего ещё начать, как не с хорошо знакомого тега div? И сразу же я наткнулся на такое примечание в спецификации:

Авторам настоятельно рекомендуется рассматривать элемент div как элемент на крайний случай, когда никакой другой элемент не подходит. Использование более подходящих элементов, чем элемент div, обеспечивает большую понятность для читателей и более лёгкую поддержку для авторов.

Начало было безусловно хорошим, и я решил дальше пролистать документацию в поисках чего-нибудь, что позволило бы мне утвердиться в своём мнении. Помните элемент hr? Что ж, оказывается, что он нужен не просто для рисования посреди экрана линии с резными, скошенными или выпуклыми краями. На самом деле, он очень семантичен.

Элемент hr представляет собой тематический разрыв уровня абзаца, т.е. изменение места действия в истории или переход к другой теме внутри раздела в справочнике.

Ух ты! Вот в этом месте мне стало действительно интересно. Я должен узнать больше! Какими ещё допущениями я руководствовался при вёрстке?

Как насчёт скромного элемента абзаца?

Элемент p не следует применять, когда есть более подходящие узкоспециализированные элементы. Следующий пример технически корректен:

 <section>
     <p>Последнее изменение: 2001-04-23</p>
     <p>Автор: fred@example.com</p>
 </section>

Однако, это было бы лучше разметить как:

 <section>
     <footer>Последнее изменение: 2001-04-23</footer>
     <address>Автор: fred@example.com</address>
 </section>

Или:

<section>
    <footer>
        <p>Последнее изменение: 2001-04-23</p>
        <address>Автор: fred@example.com</address>
    </footer>
</section>

Ладно, это не так впечатляет, но всё же, применение более подходящих тегов footer и address — это круто. Считая, что я уже знаю всё, что только можно знать про семантику абзацев, я увидел в спецификации примечание:

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

<p>К примеру, это фантастическое предложение содержит пункты про</p>
<ul><li>колдунов,
  <li>перемещение быстрее скорости света и
  <li>телепатию,</ul>
<p>и подробнее рассматривается ниже.</p>

Другими словами, «нет никакой ложки».

Сквозная модель h1-h6

Плана документа (Document Outline), позволяющего использовать несколько тегов h1h6, основываясь на разделении документа на разделы, не существует.

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

Честно говоря, для меня слышать такое — это своего рода облегчение, потому как мне никогда не казалась удобной или понятной концепция множественных элементов h1 или h2 на странице. Чувство неуклюжести быстро нарастало при попытках вспомнить, какие из элементов начинают новый контекст раздела, и сколько заголовков я уже использовал. Делать проще — это здорово.

Разметка документации

Я занимаюсь исследованиями в области документации для разработчиков, и мне захотелось взглянуть на теги pre и code, чтобы убедиться, что я правильно их использую. code для ссылок внутри предложения, как например внутри этого, и pre для длинных кусков кода наподобие blockquote.

Что ж, эти допущения оказались в основном верными, но как я увидел, обычно удаётся подобрать более подходящие и более выразительные элементы. Я обнаружил ещё пару элементов, которые были специально созданы для документации кода, kbd и samp. Для меня они особенно значимы, потому что решают они две задачи:

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

Детализация кода

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

Тег var можно использовать для разметки переменных в коде, а элемент data для описания чистых данных, например, значений в табличном виде.

Вы можете поинтересоваться, какие же преимущества дают элементы data перед атрибутами data-*. Элементу data можно установить атрибут value, и когда-нибудь браузеры научатся использовать его совместно с атрибутом sortable элемента table, предоставляя авторам и пользователям механизм сортировки таблиц.

Примечание: Что касается поддержки браузерами сортировки таблиц, то тут есть большие пробуксовки, и я пока не видел ни одного рабочего примера. К тому же, раздел спецификации API DOM в HTML 5.1, посвященный этому,— это сплошная каша. Но когда это появится в браузерах, не забудьте указать роли aria-sort нужным элементам заголовка таблицы. (Спасибо Рею Камдену за ликбез.)

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

Элемент figure представляет собой поток содержимого, возможно содержащий подпись, который самодостаточен (вроде завершённого предложения) и обычно упоминается как единое целое из основного потока документа.

Обратите внимание, ни слова про изображения. Далее в спецификации идёт пример, кусок кода, размеченный с figure.

<p>В <a href="#l4">листинге</a> мы можем увидеть описание базового
интерфейса API.</p>
<figure id="l4">
  <figcaption>Листинг 4. Описание базового интерфейса API.</figcaption>
  
  interface PrimaryCore {
    boolean verifyDataLine();
    void sendData(in sequence<byte> data);
    void initSelfDestruct();
  }
  
</figure>
<p>Это API требует использования UTF-8.</p>

Ого! Это вполне толково, не правда ли? Подумайте, сколько книг вы прочитали, в которых были такие маленькие элементы figure с краю страницы, поясняющие кусок кода.

Списки определений: незаметные рабочие лошадки

Мой любимый и, по моему мнению, самый недооцененный элемент HTML в спецификации — список определений (dl). Он предназначен для разметки пар имя—значение в содержимом. Это понятие может включать в себя всё, от списка предлагаемых услуг с их описаниями до простого компонента «предыдущая статья / следующая статья», как внизу каждой страницы моего блога. Этот элемент идеально подходит для документирования истории правок страницы, причин и следствий, или, на удивление, вообще любого списка, в котором используется группировка с заголовками. До прочтения спецификации я даже не догадывался, что, оказывается, вполне допустимо иметь один dt (термин) и несколько dd (определений). Вот отличный пример из спецификации, указаны различные произношения в английском, хотя определение одно и то же.

<dl>
  <dt lang="en-US"> <dfn>color</dfn> </dt>
  <dt lang="en-GB"> <dfn>colour</dfn> </dt>
  <dd> A sensation which (in humans) derives from the ability of
  the fine structure of the eye to distinguish three differently
  filtered analyses of a view. </dd>
</dl>

Проницательные читатели и знатоки HTML могут поинтересоваться насчёт редко применяемого элемента dfn и о том, как он вписывается в семантику списков описаний. dfn спецификация описывает так: «определяющее вхождение термина». В сочетании с элементами abbr и a он может значительно облегчить читателю задачу поиска первого появления термина в тексте. Вот пример из спецификации:

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

<p><dfn><abbr title="устройство открывания гаражных ворот">УОГВ</abbr></dfn> —
это устройство, позволяющее командам исследователей открывать ирисовую диафрагму.</p>
<!-- ... далее в документе: -->
<p>Тил'к активировал своё
<abbr title="устройство открывания гаражных ворот">УОГВ</abbr>,
и Хаммонд отдал команду открыть диафрагму.</p>

С использованием элемента a ссылку можно сделать явной:

<p><dfn id=gdo><abbr title="устройство открывания гаражных ворот">УОГВ</abbr></dfn> —
это устройство, позволяющее командам исследователей открывать ирисовую диафрагму.</p>
<!-- ... далее в документе: -->
<p>Тил'к активировал своё
<a href=#gdo><abbr title="устройство открывания гаражных ворот">УОГВ</abbr></a>,
и Хаммонд отдал команду открыть диафрагму.</p>

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

Это только начало

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

С следующей статье мы погрузимся в HTML завтрашнего дня и то, как бы он мог выглядеть, если бы разрабатывался сегодня.