HTML5 разметка со смыслом

HTML5. Семантика или разметка со смыслом

* Это вторая статья из серии погружения в HTML5 — их можно рассматривать как заметки к более объемному труду, который также постепенно готовится, но вместе с тем, они могут служить и просто кратким в введением в тематику HTML5*

Семантика — это о понимании значения. Сегодня мы поговорим о важности смысловой разметки верстки и извлечении данных, традиционных подходах и новых возможностях, предоставляемых стандартом HTML5.




(Для жаждущих дополнительного вдохновения, сразу рекомендую статью Вадима Макеева про семантическую верстку в двух частях — раз и два, а также его доклад с РИТ про верстку со смыслом.)
О чем мы будем говорить и почему это важно?
Говорить, или размышлять, мы будем о смысле и структуре. Это, если коротко.
На самом деле, очевидное предположение о том, что документ должен быть не просто осмысленным, но и осмысленно размечен, а структура этого документа должна быть не абы как, а тоже продуманной и логичной, можно даже попытаться подвергнуть сомнению.
Например, если вы сделаете страшное — заглянете в исходный код страниц Google Mail, вы увидите там ужасных монстров автоматической генерации кода, в которой и черт голову сломает :) Такие монстрики, конечно, живут, не только у Гугла, но факт заключается в том, что в большинстве случаев это не мешает пользоваться приложением.
Вообще все разговоры о семантике и структуре можно свести к вопросу извлечения смысла. Эта задача возникает в трех ключевых точках:

1. Разработка или дизайн
2. Автоматический анализ
3. Человеческое восприятие

В каждом из этих случаев есть свои нюансы относительно того, насколько и в чем именно важна структура и правильная семантика, но в любом случае, надо понимать, все эти вопросы очень сильно взаимосвязаны — приведу простой пример.
Представьте, что вы делаете какое-то веб-приложение и не сильно заботитесь о том, как будет внутри выглядеть конечный код, например, вы пользуетесь средствами генерации кода из другого языка (например, Java или C#) или исключительно визуальным дизайнером, который генерирует код для вас (ха, например, сохраняете страницу из Word). Когда дело доходит до отладки страницы в реальных условиях, наступает легкий приступ паники от окружающих вас непролазных джунглей и неведомых зверей — вплоть до того, что вы можете потратить несколько часов, чтобы понять, откуда именно вылезла та или иная строчка кода и где ее нужно править.
Безусловно, постепенно эта проблема сглаживается и будет продолжать сглаживаться — как за счет более грамотной генерации, так и за счет более умных инструментов разработки и отладки.
Разразработка и дизайн. Ключевой момент — это понятность и логичность кода, как для вас, так и для ваших коллег, которые работают с вами сегодня или будут поддерживать ваш код завтра. По умному это можно назвать управлением или даже уменьшением рисков, по факту это вопрос сильного контроля за развитием ситуации — от начального кода и до того, что увидят и насколько легко смогут это понять поисковые машины или обычные люди.
Если структура вашего кода логична и прозрачна, то есть соответствует некоторым соглашениям по верстке (например, правильному применению тегов и атрибутов), то жить от этого легче будет не только вам, но и другим участникам цепочки потребления контента.
Автоматический анализ. В предположении, что сайты и приложения делаются для того, чтобы ими пользовалось как можно больше людей, вопрос продвижения контента стоит в числе первых решаемых задач, которые должны учитываться уже на уровне разработки веб-сайта или приложения.
Реальность такова, что чем более четкая и понятная внутренняя структура вашего контента, тем легче автоматически (например, поисковым пауком) извлечь и далее понять его смысловое содержание. Вплоть до банального: где основной текст, где даты, где места, где упоминания людей и как они связаны с основным контентом, а где баннеры, чтобы их игнорировать, и где навигация, чтобы по ней перемещаться?
Облегчить решение этих задач как раз и может правильная разметка контента.
Другой важный момент, где автоматическое извлечение и понимание контента играет огромную роль — это вопросы доступности (accessebility), когда, к примеру, человек, чтобы взаимодействовать с вашей станицей использует специальные программы (screen reader), которые в свою очередь, чтобы сделать это взаимодействие возможным, как раз должны понять, что есть на вашей странице, какая роль у каждого кусочка и какие возможности вы предоставили пользователю. Все это делается на основании изучения кода станиц.
Человеческое восприятие. Помимо упомянутого вопроса доступности, есть и другие важные моменты. Например, решение задачи работоспособности вашего сайта в различных условиях (разные браузеры, разные ОС, разные устройства, включая мобильные), где правильная разметка и правильные подходы вроде разделения верстки и представления (стилей), могут сэкономить уйму времени.
Или же возможность лучше взаимодействовать с контентом на вашей странице, например, заносить события в календарь, сразу открывать почтовое приложение для коммуникации с человеком, предоставлять пользователю адаптированную под элемент ввода клавиатуру на мобильном устройсте (к примеру, для ввода телефона надо показать сразу цифровую клавиатуру).
Семантика сегодня: от тегов и атрибутов к классам и микроформатам
На сегодня есть в общем-то устоявшиеся подходы к тому, как должна выглядеть верстка и как к ней должно относиться. Вкратце это можно свести к следующему:

Сегодня правильный подход к верстке веб-страниц, безусловно, начинается с того, что нужно отделять содержательную часть от представления и логики, другими словами, выносить стили в CSS-файлы, а всю логику, по возможности, в файлы JavaScript. В разметке страницы должны быть контент и правильная структура.
Конечно, могут быть какие-то исключения и отклонения — и это во многом вопрос соглашений того, что считать хорошим или дурным тоном. Конечно, для колоночной верстки можно использовать и таблицы, но сегодня это уже считается моветоном: для размещения элементов по странице предпочтительно использовать правильные блочные элементы с соответствующими стилевыми правилами, а таблицы оставить именно для табличного контента.
Текущий стандарт HTML также несет в себе специальные теги для разметки содержимого: от выделения заголовков и параграфов, до специальных тегов разметки внутри текста.
Другие важные элементы — это разумное именование id и классов в элементах и правильное использование заголовочных (title) или альтернативных (alt) атрибутов, которые также, безусловно, добавляют смысла.
Наконец, нельзя не упомянуть микроформаты — правила разметки специальных типов данных вроде событий и людей, которые позволяют единообразно автоматически вытаскивать нужную информацию из страниц.
Наконец, переходим к HTML5!
НTML5 продолжает линию правильной семантической разметки контента страниц, добавляя как новые структурные и текстовые теги, так и расширяя работу с атрибутами:

Структурная семантика
Традиционная сегодня, блоковая верстка страниц никуда не уходит, но видоизменяется — в HTML5 появляются новые элементы для еще более осмысленной разметки страницы.
(Оставляю на усмотрение читателя изучить самостоятельно историю появления новых тегов и выяснения, почему они именно такие — это, правда, интересно!)
Если сегодня мы делаем примерно вот так:

<div class="header"> 
  <h1>...</h1> 
  <h2>...</h2>
</div>
<div class="section"> 
  <div class="article">
    ...
  </div>
</div>
<div class="sidebar">...</div>
<div class="footer">...</div>

То с новыми элементами HTML5 эта разметка преображается в более красивую и стройную фигуру:

<header>
 <h1>...</h1>
 <h2>...</h2>
</header>
<section>
 <article>...</article>
</section>
<aside>...</aside>
<footer>...</footer>

Возможно, вы скажете, что не сильно-то и много поменялось, и, в определенной степени, даже будете правы. На практике, например, с точки зрения CSS единственное заметное изменение — это переход от классов к тегам. Код стал короче, но не то, чтобы очень.
Зачем тогда все это? Ответ, на самом деле, очень прост — единообразие. В реальности, если я хочу понять автоматически, где тут навигация по названиям классов, то я столкнусь и с “nav”, и с “navigation”, и c “menu” и тысячей других вариантов, не говоря уже о транслитерации с русского ;)
Если я знаю, что навигация — это всегда элемент <nav>, моя жизнь сразу обретает радостные краски.
В HTML5 есть целый ряд таких новых элементов — и мы не будем останавливаться на каждом из них подробно:

• header и footer — группировка заголовочных и подвальных элементов, важный момент — они могут встречаться не только наверху и внизу страницы, но и внутри различных блоков, если в них имеет смысл выделять собственные заголовочные и подвальные блоки (например, вставленный виджет).
• aside — врезка слабо связанного с содержимым страницы (от просто интересной информации до баннеров)
• hgroup — группировка нескольких заголовочных элементов (h1 - h6) в единый блок.
• nav — группировка элементов навигации
• section — общий блок для документа или раздела приложения
• article — отдельный кусок контента, например, пост в блоге или статья в газете
• figure и figurecapture — вставка дополнительного, но в общем-то самостоятельного контента, вроде схем, видео, картинок. Может быть с подписью.

Это блочные элементы — и вы спокойно можете их использовать уже сегодня для всех браузеров, которые поддерживают HTML5.
Что делать, если браузер не поддерживает HTML5?
В этом случае вы все равно можете продолжать использовать эти элементы, но с друмя дополнительными правками:
1. Нужно сказать браузеру, что эти элементы блочные с помощью соответствующих css-правил:

article, aside, figcaption, figure, footer, header, hgroup, nav, section
 {
     display:block;
 }

2. Для браузеров, которые не поддерживают по умолчанию вставку нестандартных (для HTML4) элементов, нужно инициализировать возможность их использования через JavaScript. В целом, достаточно сослаться на библиотеку html5shim:

<!--[if lt IE 9]> <script src="scripts/html5.js"></script> <![endif]-->

(К слову, это верно не только для старых версий IE, но и для старых версий других браузеров, если среди вашей аудитории если любители раритета.)
Текст и контент
Другой блок больших нововведений и изменений касается вставки текстового и и другого контентного содержимого (учтите, что я намеренно не рассматриваю в этой статье графические и мультимедийные элементы, а также элементы веб-форм):

• mark — маркерное выделение фрагмента текста (по умолчанию — черный шрифт на желтом фоне), релевантное в другом контексте (например, веб-версия документа, в котором кто-то уже выделил маркером фрагменты текста).
• ruby, rt и rp —специальные элементы для аннотации текста, как правило, используемые при работе с иероглифами для уточнения смысла в текущем контексте.
• bdi — специальный элемент для изоляции из основного контекста блока для двунаправленного форматирования текста (это важно при смешении текстов на разных языках, например, английском и иврите, — в этом случае нужно логически обозначить, какой блок текста относится к другому семейству языков и поэтому при отображении может быть обработан иначе). См. также пост Ричарда Ишида (Internationalization Activity Lead, W3C) — html5′s new bdi element.
• wbr — рекомендация по месту разрыва текста в случае переноса на другую строку — может быть полезно как в случае ”неразрывной” “в одно слово” фразы, так и внутри длинных слов. Нужно, чтобы обеспечить возможность корректных переносов, если слово не умещается в отведенные рамки.
• summary и details — краткая версия и дополнительные подробности (детали), которые пользователь, возможно, хочет также получить. Браузер должен обеспечивать возможность скрыть или показать детали.
• time — специальный элемент для обозначения дат и времени и обеспечения возможности автоматического извлечения этих данных в стандартном формате (то есть, например, внутри можно написать 4 августа, а в атрибуте нужно указать 2011-08-04).
• meter и progress — еще два элемента для смысловой разметки измеримых данных, соответственно, измерения состояния чего-либо (счет, загруженность диска и т.д.) и прогресса в каком-то измерении. В зависимости от обстоятельств, конкретная визуализация этих элементов может быть различной. (К слову, в стандарте оба этих элемента относятся к блоку Controls & Forms.)
• embed — наконец-то, в стандарте ;)

Двигаемся дальше — на повестке дня вопрос дополнительного наполнения смыслом текста и элементы, роль которых изменилась (некоторые мелкие изменения, в том числе изменения в атрибутах мы оставим за рамками этой статьи).
В стандарте HTML5 отчетливо проявилось стремление расставить все точки над i, выкинуть все лишнее (т.е. стилистическое) и, в частности, убрать дублирование элементов там, где это имеет смысл.

• dl — для описания пар элементов-значений (определений), но теперь никак не для диалогов.
• cite — название работы (книги, статьи, поэмы, фильма и т.п.), но не отсылка на имя автора.
• menu — теперь может использоваться для тулбаров и контекстных меню.
• address — внесено разъяснение в использование данного тега — только для контактной информации с человеком, ответственным за данную страницу, но не для обозначения любых адресов (почтовых или email) самих по себе.
• hr — тематическое разбиение на уровне параграфов (например, переход к другой истории или другой теме).
• small — дополнительные заметки, то что обычно пишется “мелким шрифтом”, вроде заметок на полях.
• em — выделение смысла, когда нужно поставить акцент на конкретное словое в предложении.
• i — выделение голосом или настроением или подчеркивание выделения из контекста (слова, чье написание обычно делается наклонным — термины, иностранные слова, названия).
• strong — выделение важности, когда нужно обозначить особо важные моменты.
• b —выделение текста из контекста без придания ему дополнительной важности, например, ключевые слова, названия продуктов, а также блоки текста, написание которых традиционно делается жирным, в том числе для переключения контекста.
• s —неверный или более нерелевантный контент.

Также стоит отметить, что для ряда элементов спецификация рекомендует использовать вместо них соответствующие правила CSS (<basefont>, <font>, <big>, <center>, <blink>, <u>, <tt>, <strike>), для еще ряда элементов рекомендуется использовать другие элементы вместо них (<applet> —> <object>, <acronym> —> <abbr>, <bgsound> —> <audio>, <dir> —> <ul>), и, наконец, фреймы рекомендуется не использовать ни при каких обстоятельствах — используйте iframe.
Осталось еще совсем немного ;)
Доступность документов
Я уже писал в начале статьи о важности доступности страниц и приложений для конечных пользователей. В хороших компаниях и у хороших заказчиков это является обязательным требованием.

Для обеспечения доступности, помимо традиционных атрибутов вроде alt и title, теперь есть специальные aria-* и role атрибуты, определяемые в соответствии со стандартом Accessible Rich Internet Applications (WAI-ARIA).
Эти атрибуты позволяют разметить роль (назначение) различных элементов разметки — будь то ссылки, заголовки или элементы меню. Так, например, элемент aside может играть как роль заметки/сноски, так и просто дополнительной информации, а то и вовсе быть блоком для поиска. И в каждом случае конкретная роль можем менять характер взаимодействия с блоком.
В целом вопрос доступности — тема, пронизывающая многие аспекты верстки веб-страниц (вплоть до написания кода на JavaScript) и хороший предмет для отдельной большой статьи.
Переходим к заключительному краткому блоку!
Как встроить данные в документ
Последний важный блок, продолжающий тему добавления дополнительной информации к контенту страниц.
К этому моменту мы уже вспомнили про id, классы, стандартные атрибуты и даже микроформаты, позволяющие придать разметке еще больше семантики, кратко рассмотрели, что различные новые теги (как на уровне структуры, так и на уровне контента), позволяющие дать более осмысленное и стандартизованное определение назначения элементов, и перешли к вопросу доступности контента и возможности описания ролей отдельных элементов.
Но и всего этого может оказаться мало. Иногда требуется снабдить элементы дополнительной информацией — и традиционный подход в виде хранения информации в стандартных или собственных атрибутах, вообще говоря, не всегда подходит. Первый способ — это, как правило, использование элемента не по прямому назначению, а второй — просто напросто нестандартный и не должен проходить валидацию.

HTML5 добавляет возможность плодить в любом количестве собственные data-* атрибуты и иметь к ним программный доступ внутри приложения (как к обычным атрибутам или через интерфейс dataset). Важный нюанс заключается в том, что эти атрибуты предназначены для внутреннего использования внутри страницы или приложения и, вообще говоря, не должны использоваться для предоставления информации внешним сущностям (как это делают, к примеру, микроформаты).
Наконец, есть еще одна важная опция для аннотации данных — это HTML MicroData, требующая отдельного рассмотрения.
И в заключение
Надеюсь, этот длинный экскурс в семантическую историю HTML5 поможет вам лучше разобраться в возможностях нового стандарта. Продолжение погружния, больше практических примеров и деталей — в следующих постах.
p.s. Как всегда, если найдете в этом длинном повествовании нехватающие важные элементы, неточности или ошибки, дайте знать.