Избегаем популярных ошибок в HTML5

Ричард Кларк 27 июля 2011

Разбирая сайты для Галереи HTML5 и отвечая на вопросы читателей на сайте Доктор HTML5, я вынужден просматривать целую кучу страниц на HTML5 и, конечно же, их исходный код. В этой статье я расскажу вам об ошибках и сомнительной разметке, которые мне частенько приходится видеть, и объясню, как их избежать.

Не используйте <section> как обёртку для оформления

Одна из самых распространённых проблем, которую я часто вижу в разметке сайтов — это произвольная замена элементов <div> структурными элементами из HTML5, особенно замена оформительской обёртки на <section>. В XHTML или HTML4 я бы увидел что-нибудь такое:

	<!-- Не копируйте этот код! Он неправильный! -->
	<div id="wrapper">
	    <div id="header">  
	        <h1>Моя супер-пупер страница</h1>
	        <!-- Содержимое шапки -->
	    </div>
	    <div id="main">
	        <!-- Содержимое страницы -->
	    </div>
	    <div id="secondary">
	        <!-- Вторичное содержимое -->
	    </div>
	    <div id="footer">
	        <!-- Содержимое подвала -->
	    </div>
	</div>

Вместо этого я вижу следующее:

	<!-- Не копируйте этот код! Он неправильный! -->
	<section id="wrapper">
	    <header>  
	        <h1>Моя супер-пупер страница</h1>
	        <!-- Содержимое шапки -->
	    </header>
	    <div id="main">
	        <!-- Содержимое страницы -->
	    </div>
	    <section id="secondary">
	        <!-- Вторичное содержимое -->
	    </section>
	    <footer>
	        <!-- Содержимое подвала -->
	    </footer>
	</section>

Честно говоря, это неправильно: <section> — это не обёртка. Элемент <section> определяет смысловую секцию содержимого для создания структуры документа. Он должен содержать заголовок. Если вы ищете элемент для того чтобы обернуть в него всю страницу (в стиле HTML или XHTML), подумайте, не применить ли стили непосредственно к элементу <body>, как описано у Крока Кеймена. Если же вам всё ещё нужна дополнительная обёртка, используйте <div>. Раз уж Доктор Майк объясняет, что <div> не мёртв, а вам не удаётся найти ничего более удачного, пожалуй, этот элемент будет самым подходящим для создания оформительской обёртки.

Таким образом, корректной разметкой для упомянутого выше примера с использованием HTML5 и пары ролей ARIA будет следующий код. Обратите внимание, что вам, в зависимости от дизайна, всё ещё могут понадобится экстра-элементы <div>.

	<body>
	    <header>  
	        <h1>Моя супер-пупер страница</h1>
	        <!-- Содержимое шапки -->
	    </header>
	    <div role="main">
	        <!-- Содержимое страницы -->
	    </div>
	    <aside role="complementary">
	        <!-- Вторичное содержимое -->
	    </aside>
	    <footer>
	        <!-- Содержимое подвала -->
	    </footer>
	</body>

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

Используйте <header> и <hgroup> осознанно

Элемент <hgroup> удалён из спецификации HTML5 и не рекомендован к использованию, прим. редактора.

Нет смысла писать разметку, если этого можно не делать, так ведь? К сожалению, я часто вижу элементы <header> и <hgroup> там, где они совсем не нужны. Вы можете узнать все подробности в наших статьях, посвящённых элементу <header> и элементу <hgroup>, но я коротко резюмирую:

  • Элемент <header> представляет собой группу вводного содержимого или навигационных средств и обычно содержит структурный заголовок.
  • Элемент <hgroup> группирует набор элементов от <h1> до <h6>, представляя собой структурный заголовок в случае, когда заглавие имеет несколько уровней, вроде подзаголовков, альтернативных названий или слоганов.

Злоупотребление <header>

Думаю, что вы в курсе, что <header> можно использовать в документе несколько раз. Но эта возможность привела к следующим ошибкам:

	<!-- Не копируйте этот код! Он неправильный! -->
	<article>
	    <header>  
	        <h1>Мой лучший пост</h1>
	    </header>
	    <!-- Содержимое записи -->
	</article>

Если ваш <header> содержит единственный заголовок, избавьтесь от ненужного <header>. Элемент <article> в любом случае гарантирует, что заголовок войдёт в смысловую структуру документа. И поскольку <header> не содержит нескольких элементов, как указано в его описании, зачем вам код, который, в общем-то, не нужен? Будьте проще:

	<article>
	    <h1>Мой лучший пост</h1>
	    <!-- Содержимое записи -->
	</article>

Неправильное использование <hgroup>

Раз уж зашла речь о заголовках — я часто вижу неправильное использование <hgroup>. Не следует использовать <hgroup> в сочетании с <header> в случае, когда:

  • дочерний заголовок всего один или
  • элемента <hgroup> будет достаточно и без <header>.

Первая проблема выглядит так:

	<!-- Не копируйте этот код! Он неправильный! -->
	<header>
	    <hgroup>  
	        <h1>Мой лучший пост</h1>
	    </hgroup>
	    <p>Ричард Кларк</p>
	</header>

В этом случае стоит избавиться от <hgroup> и оставить только заголовок:

	<header>
	    <h1>Мой лучший пост</h1>
	    <p>Ричард Кларк</p>
	</header>

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

	<!-- Не копируйте этот код! Он неправильный! -->
	<header>
	    <hgroup>  
	        <h1>Моя компания</h1>
	        <h2>Основана в 1893 году</h2>
	    </hgroup>
	</header>

Когда <hgroup> — это единственный дочерний элемент <header>, то какой смысл в этом <header>? Если в нём нет дополнительных элементов, соседствующих с <hgroup>, смело избавляйтесь от <header>.

	<hgroup>  
	    <h1>Моя компания</h1>
	    <h2>Основана в 1893 году</h2>
	</hgroup>

Больше примеров использования <hgroup> вы можете найти в отдельной, более подробной статье.

Не оборачивайте все списки ссылок в <nav>

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

Элемент <nav> представляет собой часть страницы, которая ссылается на другие страницы или части текущей, то есть раздел с навигационными ссылками.

Замечание: не все группы ссылок на странице должны быть обёрнуты в элемент <nav> — этот элемент, главным образом, предназначен для группировки главных навигационных блоков. В частности, в подвалах часто содержатся короткие списки ссылок на различные части сайта, вроде правил использования сервиса, домашней страницы и копирайтов. Элемента <footer> вполне достаточно для группировки такого рода ссылок; и несмотря на то, что элемент <nav> может быть использован в таких случаях, обычно в этом нет необходимости.

Спецификация WHATWG HTML

Ключевая фраза — «главных навигационных блоков». Мы можем дискутировать весь день о значении слова «главный», но для меня это значит:

  • Самая главная навигация;
  • Поиск по сайту;
  • Вторичная навигация (что спорно);
  • Внутренняя навигация (по длинной статье, например).

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

  • Постраничная навигация;
  • Социальные ссылки, за исключением тех случаев, когда такие ссылки являются основной навигацией, к примеру, на сайтах About Me и Flavours;
  • Тэги к записи в блоге;
  • Категории записи;
  • Навигация третьего уровня;
  • Подвалы, набитые ссылками.

Если вы не уверены, стоит ли оборачивать список ссылок в <nav>, просто спросите у себя: «главная ли это навигация?» Чтобы было легче ответить на этот вопрос, обратитесь к следующим правилам:

  • «Не используйте <nav>, если кажется, что в этом случае может подойти и <section> с заголовком <hx>», — Ян Хиксон, IRC.
  • Добавите ли вы этот блок в список ссылок «перейти» для улучшения доступности?

Если ответ на оба эти вопроса «нет», то, скорее всего, это не <nav>.

Общие ошибки с элементом <figure>

Ах, <figure>. Правильным использованием этого элемента вместе с подельником <figcaption> не так-то просто овладеть. Рассмотрим некоторые общие проблемы, которые я вижу при использовании <figure>.

Не каждая картинка это <figure>

Ранее я советовал вам не писать лишний код там, где этого не требуется. Та же ошибка и здесь. Я видел сайты, где каждая картинка была обёрнута в <figure>. Нет никакой необходимости в добавлении экстра-разметки вокруг картинок только ради самого процесса. Вы просто делаете лишнюю работу и нисколько не улучшаете описание содержимого страницы.

Спецификация обозначает <figure> как «содержимое в потоке, с необязательным заглавием, самодостаточное, обычно упоминаемое в качестве смысловой единицы в основном тексте». Как раз в этом состоит вся красота элемента <figure>, который может быть перемещён из основного содержимого, скажем, в колонку, что никак не повлияет на основной поток документа.

Если это исключительно оформительская картинка, никаким образом не упомянутая в основном документе, то это точно не <figure>. Есть и другие варианты использования, но просто спросите себя: «Нужна ли эта картинка для лучшего понимания контекста?» Если нет, то это вероятно не <figure>, а, возможно, <aside>. Если да, спросите себя: «Можно ли переместить эту картинку в примечания к тексту?» Если ответ на оба вопроса «да», то это, вероятнее всего, <figure>.

Ваш логотип — это не <figure>

Плавно переходим к следующей проблеме, вышеупомянутые правила применимы и к ней. Вот пара регулярно встречающихся примеров:

	<!-- Не копируйте этот код! Он неправильный! -->
	<header>
	    <h1>
	        <figure>
	            <img src="logo.png" alt="Моя компания">
	        </figure>
	        Название компании
	    </h1>
	</header>
	 
	<!-- Не копируйте этот код! Он неправильный! -->
	<header>  
	    <figure>
	        <img src="logo.png" alt="Моя компания">
	    </figure>
	</header>

Добавить здесь нечего: это совсем неправильно. Мы можем спорить до посинения насчёт того, должно ли лого находиться внутри <h1>, но мы здесь не за этим. Настоящая проблема — в неправильном употреблении <figure>. Этот элемент должен использоваться, только если он упоминается в документе или контексте общего структурного элемента. Будет честным признать, что ваш логотип вряд ли будет упомянут подобным образом. Просто не делайте так. Всё, что вам нужно, это:

	<header>
	    <h1>Название компании</h1>
	    <!-- и всё остальное здесь -->
	</header>

Элемент <figure> — это не только картинки

Другое распространённое заблуждение насчёт <figure> — что он может быть использован только для картинок. Это не так. Элемент <figure> может быть видео, аудио, графиком (на SVG, к примеру), цитатой, таблицей, блоком кода, фрагментом текста или любой комбинацией этих и многих других элементов. Не ограничивайте использование <figure> только картинками. Наша работа, как энтузиастов от веб-стандартов, заключается в том, чтобы максимально точно описывать содержимое при помощи разметки.

Некоторое время назад я писал про <figure> детальнее. Рекомендую почитать, если вам интересно узнать подробности или просто освежить знания.

Не используйте ненужные атрибуты type

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

Дело в том, что в HTML5 не нужно добавлять атрибут type для элементов <script> и <style>. Если эти элементы автоматически добавляются вашей CMS, то избавиться от них может быть непросто, но если вы пишете код руками или полностью контролируете шаблоны, то нет никакого смысла писать избыточные атрибуты. Поскольку все браузеры ожидают, что скриптами будет JavaScript, а стилями CSS, вам это совсем не нужно:

	<!-- Не копируйте этот код! Он неправильный! -->
	<link type="text/css" rel="stylesheet" href="styles.css">
	<script type="text/javascript" src="scripts"></script>

Вместо этого просто напишите:

	<link rel="stylesheet" href="styles.css">
	<script src="scripts"></script>

Кроме того, вы можете уменьшить объём кода, который пишете для задания кодировки документа и других вещей. Глава про семантику в «Погружении в HTML5» Марка Пилгрима объясняет всё.

Неправильное использование атрибутов форм

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

Одиночные атрибуты

Некоторые новые атрибуты для элементов форм являются одиночными, и только одно их присутствие в разметке обеспечивает смену поведения. Эти атрибуты включают:

	autofocus
	autocomplete
	required

Надо признаться, я нечасто встречал подобное, но если в качестве примера взять атрибут required, то попадалось следующее:

	<!-- Не копируйте этот код! Он неправильный! -->
	<input type="email" name="email" required="true">
	<!-- Ещё один плохой пример -->
	<input type="email" name="email" required="1">

В конечном счёте это никому не вредит. HTML-парсер видит атрибут required в разметке, поэтому требуемая функциональность будет включена. Но что, если поставить код вверх ногами и написать required="false"?

	<!-- Не копируйте этот код! Он неправильный! -->
	<input type="email" name="email" required="false">

Парсер по-прежнему увидит атрибут required и применит поведение, несмотря на то, что вы пытались сказать ему не делать этого. Явно не то, что вам было нужно.

Существует три правильных способа задания одиночных атрибутов, второй и третий из которых нужны только если вы пишете XHTML:

	required
	required=""
	required="required"

Если применить эту запись к нашему примеру (в HTML), получится следующее:

	<input type="email" name="email" required>

Резюме

Было бы просто невозможным перечислить здесь все странные приёмы и образцы разметки, с которыми мне довелось столкнуться, но эти — одни из самых часто встречавшихся. А какие ещё ошибки разметки бросались вам в глаза? Расскажите в комментариях.

Перевод оригинальной статьи «Avoiding common HTML5 mistakes» Ричарда Кларка (Richard Clark), опубликованной на сайте HTML5Doctor.com.

Теги: , , , ,

Комментарии +

  1. Владимир Кузнецов 27 июля 2011 в 19:37

    Быстро проверить корректность структуры документа мне помогает инструмент h5o http://code.google.com/p/h5o/

    Когда article, section, nav остается без заголовка (а это сразу выявляется в структуре), то нужно либо дать блоку осмысленный заголовок, либо заменить его на div. Памятуя об этом правиле, можно избежать неуместного использования новых тегов, мне кажется.

  2. Лев Солнцев 27 июля 2011 в 19:43

    Стоить отметить комментарии к оригинальной статье, в которых говорится, что Internet Explorer не распознает атрибут required. Так, используя jQuery, запрос вида $('input[required]') при наличии <input required/> ничего не вернёт в Internet Explorer 8 и ниже. Но $('input[required=""]') при <input required=""/> даст результат.

  3. B@rmaley.e> 27 июля 2011 в 22:31

    Забавно, я перевел эту же статью для Хабра, но эту заметил только сейчас (после обновления RSS фида).

  4. Вадим Макеев 27 июля 2011 в 22:33

    B@rmaley, статья хорошая — понятное дело, хочется перевести.

  5. Антон Платонов 28 июля 2011 в 0:22
    
    <script href="js/scripts"></script>
    
    

    Атрибут href тут правильно указан вместо привычного src, или это ошибка?

  6. Вадим Макеев 28 июля 2011 в 0:30

    Антон, спасибо — это была опечатка в оригинальной статье, поправил.

  7. Петр 28 июля 2011 в 4:19

    Не «экстра-элементы div», а «дополнительные элементы div». То же самое насчёт «экстра-разметки вокруг картинок» (лучше: «избыточной разметки вокруг картинок»). В остальном перевод хороший.

  8. Сергей 28 июля 2011 в 8:22

    Кажется пропущен предлог "с" в предложении "Правильным использованием этого элемента вместе подельником не так-то просто овладеть."

  9. Вадим Макеев 28 июля 2011 в 10:37

    Петр, что касается «экстра-элементов div», то согласен — там смысл немного другой, поправил. А вот что касается экстра-разметки, то это уже профессиональная лексика, ничего не поделаешь, все говорят именно экстра-разметка.

    Сергей, поправил, спасибо.

  10. crwin 28 июля 2011 в 10:53

    Не планируете перевести статьи html5doctor? Отпала бы необходимость в подобных "разоблачениях".

  11. Вадим Макеев 28 июля 2011 в 10:56

    crwin, у нас уже переведены статьи «Элементы small и hr», «Элементы i, b, em и strong» и ещё две (про hgroup и figure) лежат в черновиках. Доктор HTML5 — это самое интересное из того, что сейчас можно переводить, так что всё будет.

  12. Петр 28 июля 2011 в 12:33

    Точно также программисты раньше говорили «аппликация» вместо «приложение» — теперь, слава богу, перестали :) В любом случае, спасибо за перевод.

  13. Павел Ловцевич 28 июля 2011 в 12:36

    Не согласен с автором по поводу неуместности использования nav для постраничной разбивки. Зачем "дробить" и ветвить код разные типы навигации?

  14. Роман Комаров 28 июля 2011 в 14:52

    Обожемой, они советуют вместо одного враппера использовать <body>. У такого решения слишком много проблем. Ну т.е. конечно, они потом говорят, что и див всё-ещё можно применять, но блин. Использование <body> для раскладки — очень, очень плохо.

    А от <hgroup>, всё же, надо избавиться. Лучшее правило его применения — просто забыть про него.

  15. Павел Ловцевич 28 июля 2011 в 19:50

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

  16. exessqd 31 августа 2011 в 10:54

    Не дело верстальщика описывать семантику страницы.

    Для кого она нужна? Для поисковиков в первую очередь, и в наименьшей степени для альт. устройств (т.к. все популярные визуальные устройства поддерживают CSS, а для screen reader'ов достаточно обозначить структуру т.е. навигацию nav и область контента article.)

    Все популярные визуальные устройства поддерживают CSS - обьясню получше, то что ты сейчас делаешь менюшку ul>li совершенно не отличается от div>div, div>span, span>span или любой другой чистой конструкции. (при необходимости эти конструкции меняются но то что нужно поисковикам будь то h1,h2,h3,h4,h5,h6,section,figure,details,nav,article,strong,em, и т.д.)

    Если семантика html5 нужна в большей стпени поисковикам то и заниматься ей должны те кто понимает в поисковиках - сеошники.
    (Что кстати на данный момент совершенно бесполезно т.к. не один поисковик не учитывает html5 семантику.)

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

  17. Вадим Макеев 31 августа 2011 в 13:08

    exessqd, семантика не нужна этим гопникам от IT или «сеошникам», им нужно сайт в топ вытащить, нагенерив уникального контента и засрав интернет дорвеями. Не вижу смысла пересказывать здесь свой доклад «Вёрстка со смыслом», вся аргументация в нём. А ещё в статье «Семантическая вёрстка», не забудьте про вторую её часть.

    Но если коротко: семантика — это методология, общий язык для разработчиков.

  18. exessqd 1 сентября 2011 в 11:20

    Видел я и доклад, и статьи читал.

    Сначала скажу я подразумеваю под бесполезной семантикой - это использование dl,dt,dd,ul,ol,li,p и т.д. вне области контента. Давайте назовем это "списковая семантика".

    Какая бывает семантика и кому она нужна?

    Семантика контентной области(h1,h2,h3,h4,h5,h6,hgroup,em,strong и т.д.) - нужна поисковикам, невизуальным устройствам.

    Структурная семантика(nav,article,aside,header,footer) - нужна
    поисковикам(в будущем), невизуальным устройствам.

    Списковая семантика - нужна никому.

    По моему мнению в статье приводится единственная адекватная причина делать "списковую семантику" - это доступность.

    Вопрос здесь в том - доступность для кого?
    Для альт. устройств, они бывают визуальные и невизуальные.

    Визуальные - телефоны(поддержка css неполная), смартфоны (полная поддержка), ридеры(полная поддержка).

    Т.е. CSS - универсален для всех визуальных устройств.
    Никто не выключает свой CSS чтобы посмотреть будет! твои dl,dt,dd,ul,ol,li,p никто не увидит.

    Невизуальные - screen readers(читалки), не учитывают списки т.е. никто твои dl,dt,dd,ul,ol,li,p не услышит.

    Как вообще появилась списковая семантика?

    Я предпологаю это было так: Какой-то перец в году 1998 выключил стили и увидел: "Опа, что-то моя страница смотрится как-то хреново, дайка я списочками все расхерачу" Он хорошо знал что такое язык разметки и сразу вспомнил "Блин! Ещё отцы основатели идеологии языков разметки говорили что оформления сайта не должно зависеть от конкретного устройства а список он и в африке список"

    Хватит творить херню и называть это семантикой, списковая семантика бесполезна.

    P.S.
    Чтобы ваш сайт был доступен с читалок не обязательно стилизовать структурные теги, делая ужасный javascript'овый fallback для старых браузеров, достаточно обернуть ваш код в них.

    Было

    
    <article class="content"></article>
    
    

    Стало

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

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

  19. Вадим Макеев 1 сентября 2011 в 17:26

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

  20. alexben 4 сентября 2011 в 10:37

    И так, я не согласен по поводу употребления тега

    <footer>
    

    , именно так, как использует Макеев Вадим. Говорим о семантике, так для кого она нужна? Конечно - прежде всего для верстальщика. А поглядывая исходный код блога pepelsbey.net, невольно улыбаешься накой черт использовать тег

    <footer>
    

    если можно использовать div или тот-же "спанчик" с классом - и ничего НЕ потеряешь. Какой логикой пользуется автор? Остается только догадываться.
    Аргументы которые он приводит в своем докладе - буквально притянуты за уши.

    Ну и статья достаточно не однозначна,особенно понравилось высказывание:

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

    http://pepelsbey.net/pres/sense-coding/
    Идем по этой посылочке и находим код, где сам Апостол нам показывает, как можно использовать nav.
    Как видите у каждого есть свои взгляды, на правильное (семантичное) использование тегов по стандарту HTML 5.
    Только это все условно и не стоит этой теме придавать особое значение. Читайте стандарты и старайтесь их не нарушать.
    А как правильно подскажет Ваша логика, а не абсурд который пишут мнимые проповедники.

  21. exessqd 5 сентября 2011 в 9:49

    если можно использовать div или тот-же "спанчик" с классом - и ничего НЕ потеряешь.

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

  22. alexben 6 сентября 2011 в 5:20

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

  23. exessqd 6 сентября 2011 в 16:44

    Раскрыл подробно из двух предыдущих комментариев, но раз ты спрашиваешь.

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

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

    
    Я "a href="http://ya.ru""ссылка"/a"
    Я "em"эмоцианальный"/em"
    Я "strong"важный"/strong"
    Я "small"второстпенный"/small"
    Я "s"неточен"/s"
    Я "cite"название работы"/cite"
    Я "q"цитата"/q"
    Я "dfn"термин"/dfn"
    Я "abbr title="""Абревиатура"/abbr"
    Я "time"время 2009-10-21"/time"
    Я "code"код"/code"
    Я "var"переменная"/var"
    Я "samp"програмный вывод"/samp"
    Я "kbd"названия клавиш"/kbd"
    Я "sup"нижний индекс"/sup"
    Я "sub"верхний индекс"/sub"
    Я "i"доп-выделение"/i"
    Я "b"ключевое слово"/b"
    Я "u"замечание"/u"
    Я "mark"подсветка"/mark"
    Я "br" разрывашка
    Я "wbr" перенос сплошного текста
    
    

    то есть элементы разметки отражают смысл содержимого а не его оформление.

    Была и другая причина - независимсоть от устройства вывода.

    Оформление нужно людям, программам нужен смысл.

    В HTML5 пошли ещё дальше и придумали структурную семантику
    section,nav,article,aside,hgroup,footer,address
    Чтобы программы могли отличать не только текст но и области содержимого.

    Кому это нужно?

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

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

    Что будет дальше?

    W3C уже давно старается реализовать концепт "семантической паутины".

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

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

    Но пока skynet не появился мы можем спать спокойно.

    P.S. Зачатки skynet можно усмотреть в проекте wolframalpha

  24. alexben 7 сентября 2011 в 4:05

    Мой не "идеальный искусственный интеллект" отказывается воспринимать конкретно тег footer, именно так, как его использует уважаемый, Вадим Макеев.
    Хотя и не нарушает спецификации :) он (прошу прощения) пытается играть на 2 фронта. Да, именно идя на поводу спецификации подстраивает свою логику.
    Я всего лишь хотел сказать, а не должно ли быть наоборот?
    Использовать правила игры во благо логике...
    Ну можно представить футер у блока, пусть даже у всех блоков/разделов. Но в комментариях зачем?

    exessqd - из всего что я понял, Вас должно огорчить то момент, что использование h1 во всех новых узлах, (т.е. употребление его многократно) может "сказочно" отразится на поисковых системах. На сколько помню, это 2 элемент важности в seo, после title.

  25. Вадим Макеев 7 сентября 2011 в 10:06

    alexben, да что ж вы пристали к Вадиму Макееву? Шоколад, как говорится, не виноват. Если можно использовать футер там, куда он логически подходит, то почему вам, как разработчику, как человеку с интеллектом, не хватает гибкости мышления, чтобы видеть в комментарии самостоятельное содержимое, которое может иметь мета-информацию, помещённую в футер?

    И ещё просьба: обратите внимание на правила оформления комментариев и оборачивайте блочные фрагменты кода в <source> (что станет pre > code), а не просто в code — это только для строчного кода.

  26. alexben 7 сентября 2011 в 23:50

    видеть в комментарии самостоятельное содержимое

    Я не вижу комментарии как самостоятельное содержимое и могу пояснить.
    Коментарии с точки зрения логики, это следствие. И между контентом есть нить, которую можно назвать причинно-следственной связью.
    Вследствие чего, вырвав из контекста любой комментарий, вероятность того, что мы поймем будет не 100%.
    И только оффтоп будет является 100% самостоятельным содержимым т.к. он никак не пересекается и не зависит от контентной части.

  27. exessqd 9 сентября 2011 в 11:40

    alexben, согласен, все правильно.
    И зачем было так кричать?

  28. Seva 10 ноября 2011 в 14:35

    Добрый день немного не по теме, но как правильнее верстать формы? а именно связь label и input например... Список определений проситься, но итак ведь есть связь for id и в придачу в спецификации везде параграфом разметка идёт...

  29. Вадим Макеев 24 ноября 2011 в 12:43

    Seva, для форм есть fieldset, legend, label и остальные элементы, уже непосредственно сами формы. Сочетая их по назначению вместе со стерильными элементами, вроде div и span, на мой взгляд, можно написать любые формы.

  30. Seva 24 ноября 2011 в 14:14

    тоесть вы считаете что внутри формы не нужно использовать дополнительные семантические теги типа p, dl, ul, ol и т.д.

    а для разметки либо если позволяет css без лишних тегов или если не позволяет то добавить стирильных? но тогда почему в спецификации они параграфами размечают?

  31. Seva 6 апреля 2012 в 14:54

    Как правильно использовать aside ?
    Например страница с описанием страны, на ней есть блок новостей относящихся к этой стране. он должен быть в aside или section, ведь по сути это раздел и имеет отношение к описанию страны, но и является самостоятельным содержимым косвенно относящимся к странице с описанием страны.

    Или например блок комментариев к новости, вроде как имеет косвенное содержимое то есть aside, но само по себе существовать не может получается section.

  32. Fktrctq 8 мая 2012 в 13:51

    Подскажите пожалуйста какие теги div блоков заменить на теги HTML5
    http://s019.radikal.ru/i604/1205/3b/56722aa5076e.jpg пример вёрстки

  33. m1ron 30 июня 2012 в 14:17

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

    Но если рассматривать html-документ как всего лишь один раздел, кусок, секцию целого проекта, тогда использвание тега section логически оправдано.
    Более того, если поместить все разделы(секции) сайта в один HTML-документ, то логическая структура проекта не нарушится (разделы сайта останутся в section, все логично). А в вашем случае они останутся в DIV'ах. Где семантика?

  34. Роман 21 августа 2013 в 20:17

    Прочитал комментарии к постам. Много спора о семантики блочных и строковых элементов. Кто - то не видит смысла использования, а другие обратное. Если разобраться тогда вообще можно не использовать семантические элементы в коде страниц, а взять не смысловые - блочный div, и строковый span, и сверстать только из них с применениями стилями CSS. Ведь по большому счету все элементы созданы для удобства их использовании для создания каркаса и вложений, а так же и строковые. Никто не принуждает использовать тот или иной стиль верстки, так как и программированию . Есть только рекомендации их использования. ))))

  35. Alex 13 октября 2013 в 2:44

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

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

  36. Евгений 13 июня 2014 в 14:18

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

    Избыточно:

    <header>
        <nav>
            <ul>
                <li><a href="#">Раздел раз</a></li>
                <li><a href="#">Раздел два</a></li>
            </ul>
        </nav>
    </header>
    <article>
        ...
    </article>
    <footer>
        ...
    </footer>

    Странно, что на одном уровне находятся и:

    <nav>
        <ul>
            <li><a href="#">Раздел раз</a></li>
            <li><a href="#">Раздел два</a></li>
        </ul>
    </nav>
    <article>
        ...
    </article>
    <footer>
        ...
    </footer>

    Главное меню не в , а содержит только один элемент:

    <header>
        <ul>
            <li><a href="#">Раздел раз</a></li>
            <li><a href="#">Раздел два</a></li>
        </ul>
    </header>
    <article>
        ...
    </article>
    <footer>
        ...
    </footer>
  37. Евгений 13 июня 2014 в 14:20

    Ко второму примеру заголовок:
    «Странно, что на одном уровне находятся <nav> и <footer>»

    К третьему:
    «Главное меню не в <nav>, а <header> содержит только один элемент»

  38. Илья 12 сентября 2014 в 13:02

    Тег hgroup по текущим реалиям deprecated
    Было бы неплохо указать об этом в статье

  39. Вадим Макеев 12 сентября 2014 в 13:34

    Илья, добавили указание, спасибо.

  40. Полина 4 августа 2015 в 13:06

    Очень полезная статья для начинающих верстальщиков. Спасибо!! ;-)

Разрешённые HTML-теги: <blockquote>, <a href="…">, <del>, <strong>, <b>, <em>, <i>.
Исходный код блочного уровня для лучшего отображения обрамляйте в элемент <source>.

Перейти к началу