Вся правда о структуре документа HTML5 стандарта.

Перевод статьи:  The truth about structuring an HTML5 page.
Автор:  Luke Stevens.

Являясь неким руководством по применению и частично посвященная обсуждению спорных нововведений HTML5 стандарта, книга Люка Стивенса «Правда о HTML5» ("The Truth About HTML5") стала причиной захватывающих дебатов. В данной статье представлены самые яркие моменты этой книги, затрагивающие проблемные стороны структуризации HTML5 документа.

The Truth About HTML5.

Данный материал представляет собой отредактированный отрывок третьей главы книги Люка Стивенса «Правда о HTML5».

Одной из наиболее рутинных задач для веб-дизайнера является разработка структуры страницы, которая, как правило, состоит из заголовочной части (шапки), завершителя (подвала), навигационного блока, боковой колонки и области контента. Порядок действий в ходе этого этапа работы над проектом у большинства разработчиков доведен до автоматизма и для вас, должно быть, не составит особого труда проделать их, как говорится, «со связанными руками и ногами».

Стандарт HTML5 предоставляет нам несколько новых элементов, предназначенных для определения структуры разрабатываемых страниц. Дополнительными компонентами используемого в этом случае набора стали — <section>, <article>, <nav>, <aside>, <header> и <footer>.

Целесообразность использования этих элементов очень сомнительна и поэтому вы не обязаны применять их в своих проектах. Они были созданы в 2004 году по прихоти (скорее всего) одного человека, который сам вряд ли вспомнит их реальное предназначение.

Да, было бы неплохо, если бы на этом все заканчивалось. Просто продолжайте использовать старый добрый способ верстки слоями, с применением дивов, назначая им осмысленные имена классов и идентификаторов, а также должным образом применяйте заголовки <h1><h6> и вы ничего не потеряете, так как этот подход будет актуален вечно (ну, или где-то в этих пределах).

Однако, я все же рекомендую использовать в своих проектах некоторые другие нововведения, которые не относятся к HTML5 стандарту, такие как атрибуты ARIA, предназначенные для облегчения работы с веб-документом слепым и слабовидящим людям, а также микроданные, описанные в словаре schema.org, которые применяются при необходимости предоставления дополнительной информации о документе поисковым системам.

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

Ложка дёгтя в бочке мёда.

Вот лишь несколько проблемных моментов, которые несут с собой новые структурные элементы:

  • Термины, взятые в качестве имен новых элементов (такие как "footer" и "header"), уже давно используются веб-разработчиками, а новый стандарт ломает устоявшиеся стереотипы, предлагая новый способ их применения и заявляя при этом, что смысл этих терминов остается прежним.
  • Представлен новый, более сложный метод структурирования документа, который не совсем понятен. Кроме того, на данный момент нет никакой необходимости в кардинальных переменах в этой области.
  • Серьезно пострадал вопрос доступности новых документов, что связано с поддержкой в некоторых браузерах (особенно это касается тех, кто пользуется IE ранних версий — 6 и 7, даже IE8 при отключенной поддержке JavaScript).
  • При этом определены размытые, нечетко обозначенные случаи использования новых элементов, что значительно усложняет процесс изучения, обучения и, как следствие, практического применения требований веб-стандартов.

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

Но новые структурные элементы производят обратный эффект. Они создают впечатление некой религиозной атмосферы, вынуждающей вас консультироваться у высокопоставленных священников (гуру HTML5) для выяснения правильного толкования замысловатых религиозных канонов (терминов HTML5 спецификации) и все это для того чтобы выполнить разметку проклятой веб-страницы.

«Да…, но ведь эти элементы официально включены в новую HTML5 спецификацию! Для этого должны быть очень веские причины» — скажите вы.

Что ж, давайте разбираться дальше.

Откуда же появились эти элементы?

Блиц-вопрос звучит так:

Как эти элементы были включены в спецификацию HTML5?

И вот варианты ответов:

  1. Эксперты рассмотрели все возможные сценарии использования, тщательно взвесили все варианты и альтернативы, и после масштабных консультаций и горячих дискуссий отобрали самые необходимые из них.
  2. Сообщество веб-дизайнеров и HTML авторов (таких как вы и я), выступило с предложением о введении новых элементов с целью обеспечения определенной функциональности. И в результате многочисленных обсуждений специалисты пришли к единому мнению, предложив окончательный список необходимых элементов.
  3. Новые элементы стали результатом научных исследований, которые предусматривали тщательное изучение структуры множества шаблонов веб-документов, взятых из их «естественной» среды — просторов Интернета.
  4. Несколько авторитетных знатоков разметки посчитали, что неплохо было бы добавить пару новых элементов и протолкнули их в следующую спецификацию, лет этак семь назад.

И правильный ответ…   4 .

«Но я ведь читал в [вставьте здесь название книги о HTML5 на ваш выбор], что это было больше похоже на третий вариант ответа. Специалисты WHATWG изучили случаи применения наиболее популярных имен классов и идентификаторов, что и стало причиной их появления».

Хорошо, мы к этому еще вернемся.

Я был не на шутку заинтригован данным вопросом и хотел любыми путями выяснить, кто инициатор добавления этих элементов, когда это произошло и почему. Поэтому задал эти вопросы напрямую редактору HTML5 спецификации Яну Хиксону (Ian Hickson) и вот его ответ (приведенный здесь с его разрешения):

«Эти элементы [были добавлены] мной и другими сотрудниками WHATWG [в] 2004 году, потому что после анализа способов применения авторами HTML4 стандарта, их актуальность была очевидна. Позже, в конце 2005 и начале 2006 года, мы провели несколько объективных исследований с целью определения десяти наиболее часто используемых имен классов для HTML элементов, результаты которых в большинстве своем абсолютно совпали с именами, добавленных нами новых элементов, что оправдало наши ожидания».

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

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

Итак, если рассматриваемые нами элементы не являются результатом исследований, тогда что же послужило реальной причиной их появления?

Исследуя темное закулисье (слава Богу, доступное для каждого) WHATWG e-mail рассылок, я обнаружил место первого упоминания этих элементов Хиксоном в ноябре 2004 года, где он обсуждал перечисленные на его интерактивной доске элементы блочного уровня.

На той же неделе он заявил — «То, о чем думаю, это [введение] нескольких секционных элементов, таких как: <body> <section> <article> <navigation> <sidebar>». (Полный текст цитируемого e-mail сообщения можно увидеть здесь.)

Ну и конечно же на определенном этапе элемент <navigation> трансформировался в <nav>, а <sidebar> стал <aside>.

В результате получается, что новые важнейшие структурные элементы, которые привлекают столько внимания, вероятней всего были включены в спецификацию благодаря тому, что Хиксон просто набросал их на своей интерактивной доске в 2004 году. Они, несомненно, имеют довольно широкое значение в «секционировании» документа (которое мы вскоре рассмотрим), но история их случайного появления в спецификации, все же, стоит внимания.

В то время как XHTML 2.0 стандарт провалился из-за своей излишней амбициозности, в вышедшей в свет HTML5 спецификации мы получаем горсть семантических элементов, написанных в порыве вдохновения редактором на своей интерактивной доске несколько лет назад и введенных в стандарт с подачи группы его коллег из WHATWG.

Кому какое дело?

«Действительно, какая разница?» — подумаете вы. «Если, в конце концов, результаты исследований подтвердили необходимость новых структурных элементов, то стоит ли вообще затрагивать эту тему?»

Суть вопроса в том, что, по моему мнению, Хиксон все же самонадеянно лукавил, говоря, что «результаты исследований в большинстве своем абсолютно совпали с именами, добавленных (*на тот момент уже добавленных) нами новых элементов». Дело в том, что эти структурные элементы, заимствуя давно используемые термины, определяют совершенно другой подход к их применению, отличающийся от уже давно устоявшегося в сфере веб-разработки. И основной проблемой является тот факт, что заложниками возникших обстоятельств являются все те же веб-дизайнеры и авторы, которые, следуя стандартам, вынуждены использовать новый метод.

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

Противоречия, возникающие при использовании новых элементов.

Видимо целью HTML5 спецификации является кодификация давно используемых в среде веб-разработки, неписаных приемов построения структуры документа, то есть новый стандарт идет «по натоптанной тропинке». Когда дело доходит до вопроса практического применения новых элементов в процессе формирования стандартного шаблона страницы, нам советуют просто заменить зачастую используемые блочные элементы <div> на новые, соответствующие им теги (к примеру, если в вашем документе имеется <div id="header">, то вам нужно заменить его на элемент <header>), вот, собственно, и все.

Кстати, эта идея была представлена в публикации «A Preview of HTML5»«Обзор НTML5 спецификации» в декабре 2007 года на сайте "ALA – AlistApart". Впоследствии она была перенесена на страницы книг и блог-посты, сопровождаясь наглядной схемой, примерно такого вида:

HTML5 wrong structure.

Это неверно, не используйте такую структуру.

Обычная замена старых блочных <div> элементов на новые – все просто, не так ли? К тому же, очень удобно, ведь одним наглядным элементом можно заменить несколько беспорядочно расположенных дивов, как мило!

Но, к сожалению, не все так безобидно и этот подход таит в себе несколько проблем:

Слишком мало элементов.
Введенных в новой спецификации элементов явно не достаточно для равноправной и однозначной замены всех блоков <div>, которые используются с целью создания отдельных частей структуры документа и их компонентов. И если вы услышите от кого-либо заявление типа — «Наконец-то я смогу избавиться от необходимости несемантического использования дивов» — плюньте ему в лицо (*Хотя автор статьи предлагает более жестокий способ расправы с такими «лжецами»).
Неравноправность.
Несмотря на то, что эти элементы зачастую представляются как функционально равноправные, на самом деле это не так. В то время как секционные элементы (<section>, <article>, <aside> и <nav>) в общем, выполняют практически одну работу, оставшиеся два <header> и <footer> предназначены для использования внутри создаваемых предыдущими элементами секций. Этот факт делает их совершенно разными (вскоре мы увидим это в примере со структурой документа), хотя в большинстве дискуссий на эту тему ничего подобного не упоминается.
Это не замена.
Если покопаться в HTML5 спецификации, то можно выяснить, что эти элементы совсем не предназначались для прямой замены уже существующих тегов. На самом деле они предназначены для создания нового вида структуры документа. Структуры, способной озадачить любого. Этот вопрос следующий на очереди.

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

Новая структура документа вызывает много вопросов.

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

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

Да, действительно, все это очень туманно. Я помогу вам разобраться в этом и покажу, что новая спецификация на самом деле навязчиво пытается представить радикально новый способ создания такой фундаментальной вещи, как структура веб-страницы. И это уже не движение «по натоптанной тропинке», а в данном случае более уместным будет сказать, что это скорее всего «дорога в никуда».

Что такое структура страницы и зачем все это нужно?

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

Каждый раз, создавая исходный код веб-страницы с использованием элементов заголовков, вы формируете структуру документа, даже не задумываясь над этим. То есть, если вы совершенно не знакомы с таким понятием как «структура документа», то это не значит, что вы не приложили к этому руку. Странно, не правда ли?

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

Так вот, HTML5 пытается в корне изменить способ формирования структуры страницы, якобы сохраняя при этом уже существующий принцип ее представления. Этот новый подход и является первопричиной введения рассматриваемых в данной статье элементов, именно он заставил Хиксона и специалистов WHATWG задуматься о введении «нескольких секционных элементов» еще на начальном этапе развития описанных здесь событий.

Давайте сделаем паузу и внимательней рассмотрим структуру создаваемых нами (иногда даже неосознанно) страниц сегодня. В предыдущих (X)HTML спецификациях используется иерархическая схема построения документа при помощи элементов заголовков различного уровня, то есть хорошо знакомых нам тегов <h1> — <h6>.

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

<h1>Название сайта</h1>
<h2>Последние статьи</h2>
<h3>Пост 1</h3>
<h3>Пост 2</h3>
<h3>Пост 3</h3>

<h3>Боковая колонка</h3>
<h4>Архив</h4>
<h4>Комментарии</h4>
<h4>Рекомендуем прочитать</h4>

<h4>Ссылки и контактная информация</h4>
<h5>Наши партнеры</h5>
<h5>Мы в соц. сетях</h5>
<h5>Обратная связь</h5>

Такая разметка приведет к формированию представленной ниже семантической структуры документа:

1. Название сайта
1. Последние статьи
1. Пост 1
2. Пост 2
3. Пост 3
4. Боковая колонка
1. Архив
2. Комментарии
3. Рекомендуем прочитать
4. Ссылки и контактная информация
1. Наши партнеры
2. Мы в соц. сетях
3. Обратная связь

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

Что ж, давайте изменим уровень элемента «Боковая колонка» на <h2> (сделаем его таким же как и у элемента «Последние статьи»). В результате имеем следующее:

1. Название сайта
1. Последние статьи
1. Пост 1
2. Пост 2
3. Пост 3
2. Боковая колонка
1. Архив
2. Комментарии
3. Рекомендуем прочитать

В последнем примере мы улучшили ситуацию, но при этом потеряли возможность придания заголовкам необходимой степени важности. Теперь для построения логической структуры документа мы пытаемся манипулировать ограниченным набором тегов (<h1> — <h6>), которые обладают «привычкой» присваивания всего, что находится под ними, даже когда это совсем не требуется.

Еще один пример. Допустим, имеется следующий исходный код:

<h2>Обзор книги о HTML5</h2>
<h3>Положительные отзывы</h3>
<p>В книге очень доступно описаны новые элементы спецификации…</p>
<h3>Отрицательные отзывы</h3>
<p>Автор использует неудачные примеры, не позволяющие понять суть
вопроса…</p>
<div class="review-body">
<p>Мне удалось купить эту книгу по удивительно низкой цене…</p>
</div>

При такой структуре документа все содержание обзора рассматриваемой книги (*див с классом review-body) будет попадать под элемент <h3>Отрицательные отзывы</h3> (*а с семантической точки зрения принадлежать образуемому им разделу документа), так как весь остальной контент находится именно под этим заголовком, несмотря на то, что по логике вещей он должен относиться к элементу более высокого уровня <h2>Обзор книги о HTML5</h2>. В большинстве случаев эта недоработка структуры остается незамеченной, так как в визуальном представлении страницы все находится на своих местах. Такая визуальная гармония достигается путем добавления нового блочного элемента <div> для отделения интересующего нас информационного блока, содержащего обзор книги, от раздела «Отрицательные отзывы» и дальнейшего его стилевого оформления.

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

Из этого можно сделать вывод, что заголовки не годятся для построения структуры документа. Зачастую они применяются к текстовым фрагментам лишь для отображения их с различными размерами шрифтов (как с привлечением CSS, так и без) или для придания им произвольного акцента, совершенно не связанного со структурой документа. А иногда доходит до того, что определенные фрагменты HTML кода вставляются непосредственно в новый документ с помощью обычного копи-паста, даже не принимая во внимание структуру его шаблона.

Если все приведенные выше неприятные моменты воспринимаются вами лишь как следствие ограничений использования набора элементов <h1> — <h6>, то это вполне объясняет тот факт, что большинство веб-страниц в сети не имеет ничего похожего с логической структурой документа.

Но в них все же присутствует структура. И наличие заголовков позволяет людям с дефектами зрения перемещаться по создаваемым нами страницам при помощи экранных дикторов, что согласно проведенным исследованиям большинство из них и делают. (К этим исследованиям мы вскоре еще вернемся). Поэтому, несмотря на все недостатки, нам, тем не менее, необходимо уделять особое внимание заголовкам при формировании структуры документа, что позволит повысить степень его доступности. Но делать это нужно осмотрительно.

Увидеть структуру любого сайта в Интернете вы можете при помощи специального расширения для Google ChromeHTML5 Outliner.

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

Секционирование документа – наболевшая проблема.

Неоднозначная ситуация с заголовками и вопрос создания структуры документа не теряют своей актуальности уже давно. Так, в первом проекте спецификации XHTML 2.0, еще в 2002 году, для создания структуры документа было предложено использование вложенных секционных элементов <section>, а для всех заголовков применение одного общего элемента <h>, важность которого зависит от степени вложенности секционного элемента, в котором находится заголовок.

Такой способ секционирования документа был впервые предложен еще в 1991 году Тимом Бернсом-Ли (*Считается основателем W3С и является руководителем этого консорциума.), цитата из прямой речи которого приводится в публикации Джереми Кейта:

«По моему личному мнению, было бы намного предпочтительнее для указания заголовков, вместо элементов <H1>, <H2> и т.д. (которые позаимствованы из AAP DTD), предусмотреть новый, допускающий вложенность элемент <SECTION>…</SECTION> и единый элемент <H>…</H>, который при размещении в секции любого уровня вложенности будет приобретать требуемый вес заголовка».

Теперь, по истечении двух десятков лет имеем ситуацию, в которой спецификация HTML5 пытается ввести в основной функционал HTML концепцию секционирования, весьма схожую с той, которая была предложена в XHTML 2.0, но оставляя при этом возможность обратной совместимости. Результаты такого нововведения, мягко говоря, неоднозначны.

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

Если мы неравнодушны к слепым пользователям, то обязаны уделять внимание заголовкам. Как мы помним из сказанного при обсуждении предыдущей, HTML4 спецификации, именно заголовки, такие как <h2>Название сайта</h2> (а не разрозненные дивы типа <div class="blog-sidebar">Боковая колонка</div>) создают структуру документа. И для слепых пользователей они действительно имеют значение.

Насколько же они важны для этих людей? Ниже приведены результаты опроса более 1000 пользователей программ чтения с экрана (80% из них слепые и 16% со слабым зрением):

«Результаты ответов на данный вопрос превзошли все наши ожидания. Важность наличия заголовков в структуре страницы для пользователей экранных дикторов не вызывает сомнения, и 76 процентов из них всегда или почти всегда перемещаются по странице с помощью заголовков, если таковые имеются. Причем, процент таких пользователей увеличивается в зависимости от опыта использования ими программ чтения с экрана. В результате имеем: профессиональные пользователи — 90,7%; опытные – 79,3%; пользователи среднего уровня – 69,9%; и начинающие — 55,4%».

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

Задумывались ли вы над этим раньше? Я – нет, и годами поневоле использовал <h1> — <h6> элементы. Нет, безусловно, большинство веб-дизайнеров имеют представление о важности заголовков, но вряд ли они осознают, насколько заголовки критичны для слепых пользователей.

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

«Улучшенная» структуризация HTML5 документа была провальной задолго до ее презентации. С понятием структуры документа мы уже с вами определились (упорядоченное представление основных разделов страницы в виде ее содержания), и к тому же установили, какой способ ее создания используется на сегодняшний день (с помощью элементов <h1><h6>).

Теперь, в двух словах ознакомимся с рекомендациями HTML5 стандарта касательно формирования структуры документа:

  • Каждый раздел (элемент) структуры или «секция» образуется при использовании одного из четырех «секционных» элементов: <section>, <article>, <nav> или <aside>, но не заголовков <h1> — <h6>. Это сделано с целью снятия ограничений, связанных с недостаточным количеством элементов <h1> — <h6>.
  • Общего заголовка <h>, предложенного в XHTML 2.0 нет. Но при создании строгого HTML5 документа рекомендуется в качестве базового заголовка использовать элемент <h1>. Кстати, любой, присутствующий в HTML5 документе заголовок, будет обрабатываться браузером как базовый, а уровень его семантической важности будет определяться в зависимости от степени его вложенности в структуру документа.
  • Но, все же такого понятия, как «строгий» HTML5 документ не существует. И поэтому мы обязаны обеспечивать обратную совместимость, а именно — продолжать использовать заголовки <h1> — <h6> в качестве логических элементов. Иными словами, поддерживать оба способа разметки в одном документе.

В этом заключается основная идея. Вот как это представлено в спецификации:

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

Убедительная просьба — не используйте элементы <h1> повсеместно.

На мой взгляд, все заинтересованные стороны (Хиксон в спецификации и публичных комментариях, сторонники стандарта в сообществе, дизайнеры и разработчики в общем) при обсуждении данного вопроса совершенно не понимали друг друга.

И следствием такой несогласованности стал тот факт, что дизайнеры и разработчики применяют новые HTML5 элементы, не имея четкого понимания того, какую, собственно, структуру они с их помощью создают. Эти элементы вводились с целью улучшения логической разметки документа. Вместо этого, благодаря их необдуманной и несогласованной реализации, они определили новый HTML5-стиль структуры документа, который еще больше несовершенен, чем тот, который он призван заменить – основанный на элементах заголовках (<h1> — <h6>).

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

Теперь немного иронии. Новый подход, который теоретически должен усовершенствовать составляющие доступности веб-ресурсов в будущем (правда никто не знает когда, и будут ли вообще программы чтения с экрана поддерживать эту разметку), уже сейчас нарушает стили документа для немногочисленной группы пользователей IE (*IE, вплоть до 8 версии игнорирует новые теги и, как следствие, находящиеся в них атрибуты стилей). То есть, уже на данный момент этот подход приносит вред, и не имеет каких-либо четких перспектив в обозримом будущем.

Копание в великих идеях, как правило, приводит к неудачным решениям.

Первопричиной провала нового подхода структурирования документа является сама используемая HTML5 стандартом идея следования по «натоптанной тропинке», т.е. кодифицирование уже давно успешно используемой практики.

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

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

2009 год, Хиксон говорит:

«Они более и менее удовлетворяют самым распространенным требованиям разработчиков, установленным на основе наиболее часто используемых значений атрибутов классов class="" . Их главное назначение – упрощение верстки и стилевого оформления».

И в 2012:

«По большей части, эти новые элементы слегка облегчают процесс верстки».

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

Сторонники HTML5 (и сама спецификация) должны четко обозначить цели и способы использования новых элементов или отменить их совсем.

Но на данный момент они просто пытаются навязать абсурдную идею всему сообществу веб-дизайнеров.

Давайте для наглядности рассмотрим один пример. В спецификации говориться, что элементы <header> и <footer> определяют отдельные области внутри разделов, но не используются для создания разделов как таковых, и поэтому не будут показаны в структуре документа. Этот момент большинством людей воспринимается неверно, и как следствие его неверная интерпретация переносится в обучающие книги по HTML5 и блоги, сопровождаясь примерами, в которых элементы <header> и <section> ставятся на один уровень. Спецификация также утверждает, что <header> и <footer> могут многократно использоваться в пределах одной страницы (к примеру, по одному разу в каждом разделе), но вы вряд ли встретите это пояснение на большинстве ресурсов, освещающих возможности новой HTML5 спецификации.

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

Мы раздвоили спецификацию.

В определенном смысле, сообщество веб-разработчиков раскололо HTML5 спецификацию на два варианта (*имеет место, так называемый форкинг), по крайней мере, ту ее часть, которая касается разметки документа. И это действительно проблема. Существует «реальная HTML5 спецификация» и ее ответвление — «общеизвестное (неверное) понимание HTML5 спецификации». Но следуя «общепринятой версии (пониманию)» и просто размечая соответствующие разделам страницы визуальные области с помощью созвучных им новых элементов, мы не получаем никаких улучшений (*ни в плане семантической структуры, ни в плане облегчения труда верстальщика). Таким образом, по причине неправильного использования новых элементов, мы создаем нечеткую, фрагментированную структуру. И имея на данный момент огромное количество HTML5 документов с некорректной структурой, можно сказать, что новый способ разметки документа как концепция провалился еще на этапе его введения.

Ниже мы подробно рассмотрим каждый элемент в отдельности, но при этом давайте будем придерживаться общей, уже сформировавшейся картины.

Как же нам структурировать страницу HTML5 стандарта?

Все выше изложенное, возможно, слегка запутало вас, поэтому давайте вернемся немного назад и рассмотрим основные правила структурирования документа (в их оригинальном виде), как они представлены в HTML5 спецификации:

  • Мы должны использовать элементы <section>, <article>, <nav> или <aside> для создания новой секции структуры (Это новый пункт в схематически представленной структуре документа). Вы можете увидеть, как выглядит структура вашей страницы при помощи плагина для Google Chrome — HTML5 Outliner. В данном правиле используется непродуманная терминология – для создания секции (раздела) документа имеется несколько элементов, включая <section>, что несколько запутанно, не правда ли?
  • Элементы <header> и <footer> должны использоваться в пределах секции с целью определения ее заголовочной части и завершителя. Этой секцией может быть что угодно – начиная от корневого <body> элемента и заканчивая блоком, содержащим отдельный комментарий. Кстати, индивидуальные комментарии теперь должны заключаться в рамки элемента <article> (о чем упоминается в четвертой главе стандарта), который образует секцию структуры документа.
  • Элементы заголовки (<h1> — <h6>) должны использоваться нами для оглавления каждой секции структуры, а также с целью обратной совместимости. (На данный момент существенной поддержки HTML5 структуры нет, и не предвидится в ближайшее время. Поэтому применительно к данному случаю «обратная» совместимость, скорее всего, является «совместимостью с обозримым будущим».)

Вы, вероятно, думаете, что сможете просто заменить все используемые вами дивы <div> на секции <section> и таким образом сформировать структуру документа. Однако элемент <section> не предназначен для тех случаев, когда вам нужно просто визуально оформить определенный блок, привязав к нему необходимые стили. Поэтому в строгом HTML5 документе вы по-прежнему будете иметь множество дивов, необходимых для визуального оформления документа. Кстати, вот что будет предусмотрено «корректным» HTML5 документом:

  • множество элементов <section>, <article>, <nav> и <aside>, необходимых для создания структуры;
  • множество дивов <div> для стилизации;
  • чрезмерное использование заголовков <h1> — <h6> с целью максимально точного дублирования структуры документа (именно такая структура на данный момент воспринимается программами чтения с экрана);
  • и внушительное вкрапление излишних <header> и <footer> тегов внутри каждого раздела, которые абсолютно не нужны.

Упрощение верстки? С применением двух способов разметки страницы, необходимостью поддержки двух видов семантической структуры и добавлением множества лишних тегов?

Мне так не кажется. И это все без учета средств, необходимых для стилизации наших заголовков.

HTML5 стилизация заголовков – это какое-то безумство. Давайте представим, что в будущем веб-документы будут разрабатываться строго по HTML5 стандарту, и мы сможем использовать лишь элемент <h1> в качестве базового заголовка, как это рекомендует спецификация. Кроме того, с целью создания структуры документа, мы, как и следует, используем секционные элементы. То есть, тег <h1>, находящийся в разделе с тройным уровнем вложенности, эквивалентен привычному для нас <h3>.

Предположим теперь, что нам необходимо задать стили для этого, вложенного на глубину трех уровней заголовка <h1> чтобы он отображался так, как подобает нормальному <h3> заголовку. Какой селектор нам нужно создать для этого элемента? Просто вообразите себе ситуацию, когда нужно добираться до множества <h1> заголовков, размещенных повсюду на разных уровнях каскадной структуры, для задания им необходимых стилевых свойств. И все это с учетом того, что все четыре, введенные спецификацией секционных элемента могут создавать секции документа и использоваться при этом в любых возможных комбинациях. Да вы забудете что такое сон!

Николь Салливан коснулась темы этого безумства, (которое имеет место всякий раз, когда вы пытаетесь задать необходимые стили характерным HTML5 стандарту <h1> элементам, расположенным глубоко в структуре документа), в своей статье с подобающим названием — «Не используйте HTML5 секции при стилизации заголовков» («Don’t Style Headings Using HTML5 Sections»), где она также приводит вот этот, прошу учесть, упрощенный пример:

h1{font-size: 36px}
section h1{font-size: 28px}
section section h1{font-size: 22px}
section section section h1{font-size: 18px}
section section section section h1{font-size: 16px}
section section section section section h1{font-size: 14px}
section section section section section section h1{font-size: 13px}
section section section section section section section h1{font-size: 11px}

Как говорит Салливан, этот пример сильно упрощен. Реальное безумство начинается тогда, когда вам необходимо определить стили для заголовков, предположим, шестиуровневой степени вложенности, которые могут находиться в недрах структуры, созданной с применением различных комбинаций секционных элементов <section>, <article>, <aside> и/или <nav>. Смеха ради взгляните на то, как может выглядеть CSS файл, содержащий такие селекторы. Вот это, действительно, предел безумия.

Единственным выходом из создавшейся ситуации будет откат к предыдущей позиции, то есть к применению имен классов для стилизации заголовков. Однако, по мнению WHATWG как-раз использование авторами имен классов и является «проблемой», которую должна была решить новая спецификация.

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

И последним штрихом, завершающим полную картину будет тот факт, что стили, определяемые для элементов <nav> (и любых других новых HTML5 элементов) не будут иметь какого-либо эффекта примерно для 1% пользователей. (*Автор имеет в виду тех пользователей, которые используют IE ранних версий, вплоть до восьмой включительно.)

Именно этот подход предлагается новой HTML5 спецификацией – полный бардак.

И не удивительно, что даже самые опытные и известные веб-разработчики довольно глубоко коснулись темы несовершенства HTML5 структуры в своих блогах. Для примера можете ознакомиться с мнением Роджера Йохансона.

И это не пустяк, создается необходимость в обучении людей всему этому.

«Ладно, ладно, пусть зубрилы гипертекстовой разметки лажанулись на этот раз. Допустим, что новые структурные элементы излишни. Поэтому никто их не использует, или всё-таки использует, но не совсем правильно. Но что это меняет, мистер Педант Разметки?»

Вопрос в том, что представляя новые элементы и саму концепцию нового, неосновательного подхода к построению структуры документа, в ее правильном, определенном спецификацией понимании, людям действительно нужно многое разъяснять. (Докатились до того, что некоторые дизайнеры обучают этому своих детей – взгляните на набор обучающих магнитов, предложенный Камероном Моллом.)

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

(Небольшое отвлечение по поводу обучения веб-стандартам: Если вы действительно ненавидите своих студентов, попросите их объяснить различие между элементами <article> и <section>.)

Основные точки расхождения.

Хиксон и сообщество WHATWG, конечно же, имели добрые намерения и, теоретически, использование новых тегов должно было улучшить доступность документов, даже если не брать в расчет их структуру. (К примеру, специализированные программы чтения с экрана могли бы перемещаться непосредственно к содержимому документа, минуя его навигационную часть, находящуюся в секции <nav>.) Но разработчики такого программного обеспечения на данный момент не проявляют особого интереса к HTML5 спецификации. Скажу больше, в своих продуктах они обеспечили поддержку более подходящей альтернативы, которую мы рассмотрим в следующем разделе.

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

Некоторые люди все равно будут применять эти теги, это в большей степени относится к тем, кто привык все делать «правильно», надеясь при этом, что добрый волшебник «Покровитель Веб-стандартов» положит им под подушку горсть мелочи и/или стильный Apple гаджет. Но такое поведение совсем не оправданно и приведет к пустой трате драгоценного времени и сил, которые можно направить в более важное русло.

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

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

Разумный подход к созданию структурированной разметки документа с целью повышения его доступности.

Существует другой, достойный способ, предусматривающий включение вспомогательного механизма, который решает проблему доступности для людей с дефектами зрения без погружения в загадочный мир новых структурных HTML5 элементов – это ARIA роли.

Вообще-то, полное имя этого механизма представлено достаточно громоздкой и сложной аббревиатурой — WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications), или на более понятном языке — «Cтандарт, обеспечивающий доступность активных Интернет приложений». Для удобства мы будем называть его просто ARIA.

Он не является частью HTML5 стандарта, а представляет собой гениальное решение специалистов консорциума W3C, составляющее независимую спецификацию ARIA, которая совместима с HTML5, HTML 4 и XHTML 1.x.

Секрет ARIA заключается в использовании атрибута role, который может включаться в состав элемента страницы, примерно вот так:

<div role="myarearole">

Полная версия спецификации ARIA очень объемная, но мы коснемся лишь небольшого его раздела, называющегося landmarks (*«Ориентиры» в пределах веб-страницы. В официальной W3C формулировке говориться: «Landmark – некий класс, определяющий область страницы, к которой пользователь может получить быстрый доступ. Содержание такой области отличается от контента других областей страницы и соответствует преследуемым пользователем целям – таким как навигация, поиск, просмотр основного контента, и т.д.»).

Для примера возьмем четыре основные области простейшей веб-страницы:

  • Header
  • Content
  • Sidebar
  • Footer

И вот как будет выглядеть ее разметка с применением ARIA landmark:

<div role="banner"></div>
<div role="main"></div>
<div role="complementary"></div>
<div role="contentinfo"></div>

Несложно, правда?

Преимущества ARIA.

Использование ARIA ролей имеет ряд преимуществ перед HTML5 и предыдущими HTML версиями:

  • Роли, в большинстве случаев, отражают именно тот вариант разметки документа, который обычно используют авторы. К примеру, заголовочная часть (*в примере Header) или баннер (*значение атрибута role для заголовочной части в примере) относятся к типу контента, который находится в верхней области страницы, а не в каждой секции документа, как это предусмотрено HTML5 спецификацией.
  • Особо не загромождая разметку, мы можем помимо применения по прямому назначению, использовать их с целью привязывания стилей для IE7 и выше, путем создания CSS селекторов атрибутов, таких, допустим, как div[role="banner"] {border:7px grey;}. (Если необходима поддержка для пользователей IE6, то вы можете включить дополнительные классы).
  • ARIA landmarks уже сейчас успешно используются различными экранными дикторами, такими как JAWS 10-й версии, NVDA 2010.1 и VoiceOver на iPhone IOS4+.
  • Они не нарушают формируемое с помощью скриптов визуальное представление веб-страницы в IE6 — 8 при отключенной в браузере поддержке JavaScript, что имеет место при использовании новых HTML5 элементов.

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

Рекомендации по созданию разметки документа.

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

  • Не следует использовать новые секционные элементы. (Посмотрим, что с ними произойдет позже, а пока доверьтесь технологии ARIA landmarks.)
  • С большей серьезностью относитесь к вопросу использования заголовков в своих проектах, принимая во внимание их важность для людей с дефектами зрения.
  • Для повышения доступности документа используйте атрибуты ARIA landmarks.
  • Для других целей продолжайте использовать дивы с семантическими именами классов или идентификаторами, собственно, так, как мы и поступали до этого.
* Примечание переводчика.

Комментариев: 2 на Вся правда о структуре документа HTML5 стандарта.

  1. Полностью согласен с автором, особенно про студентов и различия между и . Тем более, что они могут быть встроенными друг в друга.

  2. Вы думаете что слабовидящие дурачки? Думаю они могут понять важность статьи которую например они читают (нашедшую через поиск) и боковую панель непосредственно связанного с окружающим контентом, но которое может рассматриваться и отдельно.
    По поводу структуры, зачем делать коментарии в боковой панели? разве это не должно относится к постам(статьям)? Еще элемент hr представляет собой тематический разрыв уровня абзаца, т.е. изменение места действия или переход к другой теме внутри раздела. Думаю что Боковая панель(aside) может находится по структуре вложена в В Последние Статьи, в семантическом смысле она косвенно относится к основному разделу.
    множество элементов , , и , необходимых для создания структуры;
    Если сравнить с дивами разве будет меньше?
    множество дивов для стилизации;
    Что мешает использовать стилизацию для , , и ?
    Но это всего лишь моё мнение!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *