HTML5 INSIGHT


* Это вторая статья из серии погружения в 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. Как всегда, если найдете в этом длинном повествовании нехватающие важные элементы, неточности или ошибки, дайте знать.