Семантика html5

Пока в HTML 5 есть две проблемы: отсутствие обратной совместимости, так как новые семантические элементы не будут работать в 75 процентах браузеров, и отсутствие совместимости с будущими версиями, поскольку семантические элементы не являются расширяемыми. Если изобретение новых элементов — не выход, то что же делать?

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

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

HTML 5, с удвоенной силой разрабатываемый W3C в качестве следующего поколения HTML, за последний год получил значительный импульс в развитии. Это огромный проект, касающийся не только структуры HTML, но также и моделей парсинга, обработки ошибок, DOM, алгоритмов выборки ресурсов, медиа-контента, 2D-рисования, создания шаблонов для данных, моделей безопасности, загрузки страниц, хранения данных на стороне клиента и так далее.

Это также и пересмотр структуры, синтаксиса и семантики HTML, о чём частично рассказал Лаклен Хант (Lachlan Hunt) в своём «Обзоре HTML 5».

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

BBC недавно сообщила о прекращении использования формата hCalendar в списке передач из-за проблем с общедоступностью и юзабилити при использовании шаблона проектирования abbr. Это, безусловно, свидетельствует о том, что семантическая составляющая HTML достигла предела своих возможностей, в самом деле, это довольно частое явление среди языков. Нам просто не хватает элементов и атрибутов для более выразительной разметки семантики документов. Если мы продолжим использовать существующие конструкции HTML, то столкнёмся со всеми перечисленными проблемами. Но у HTML, как у языка семантической разметки, есть и более фундаментальный недостаток — его семантика фиксирована и не способна к расширению.

Это не просто теоретическая проблема. Сотни тысяч веб-разработчиков используют атрибуты class и id для создания более выразительной семантически разметки. (Они также используются для описания в CSS-стилях, но это совсем другой случай.) Почти всегда, эти веб-разработчики используют произвольную терминологию, значения, которые они сами придумали, а не взятые из существующих схем. В лучшем случае такая разметка является псевдосемантичной.

Многие веб-страницы используют микроформаты для улучшения семантической структуры существующего набора HTML-элементов и атрибутов. В этом случае, значения атрибута class устанавливаются по заранее определённым соглашениям, иногда заимствованным из других стандартов, например vCard, либо, если признанных стандартов не существует, создаётся собственная терминология (как в случае с hReview).

Расширяемая семантика

Здесь мы сталкиваемся с существенными проблемами. Нам нужны такие средства HTML, которые позволили бы веб-разработчикам создавать чёткую, однозначную и более выразительную семантически разметку (и я говорю не о псевдосемантике). Это, возможно, наиболее важная задача, стоящая перед HTML 5.

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

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

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

Итак, что же нам предлагает HTML 5? В нём вводится несколько новых элементов. Некоторые из них являются «структурными»: section, nav, aside, header и footer. Элемент dialog — это содержательный элемент, похожий на blockquote. Также введены элементы данных, такие как meter, который «служит для представления чисел в определённом интервале или дробных значений, например, количества свободного места на диске», и time, который используется для указания даты и/или времени.

Эти элементы могут быть полезны и вызывают определённый интерес, но способны ли они решить описанную нами проблему, в частности, ограничения на обратную и будущую совместимость?

Давайте рассмотрим каждойе из ограничений.

Обратная совместимость

Как браузеры обрабатывают новые элементы, например section? Что ж, последние версии Safari, Opera, Mozilla и даже IE7 сгенерируют страницу правильно.

   

Текст в элементе section.

Начало замечательное. Но если мы попробуем применить стили к элементу section:

section {color: red}

… большинство из упомянутых браузеров справятся с задачей, а вот IE7 (и, соответственно, 6) — нет.

Таким образом, мы имеем серьёзные проблемы с совместимостью в 75% используемых в данный момент браузеров. Зная «период полураспада» браузера Internet Explorer, можно предположить, что многие будут пользоваться им ещё в течение нескольких лет.

Какова вероятность, что подавляющее большинство разработчиков станут использовать эти новые элементы HTML 5, зная что они несовместимы с большинством браузеров? (Примечание переводчика: не стоит быть столь категоричным в оценках, так как доля IE7 и IE6 не составляет большинство, и, к тому же, уменьшается с каждым месяцем.)

К сожалению, если вы попытаетесь решить проблему с CSS иным способом, например, присваиванием элементу section атрибута class и использованием его в таблице стилей, то снова потерпите неудачу в IE. Возможно, есть какой-то выход, но пока он не найден, это будет серьёзным препятствием.

Давайте рассмотрим следующее ограничение — будущую совместимость.

Будущая совместимость

Зададим себе такой вопрос: «Почему мы должны придумывать новые элементы?». Разумным ответом было бы: «Потому что в HTML бедная семантика, а добавляя эти элементы мы делаем её разнообразней — неплохо, не правда ли?».

Добавляя эти элементы, мы удовлетворяем свои потребности лишь в ограниченных масштабах. Неважно, сколько элементов мы уже прикрутили, всегда будет хотеться сделать семантику ещё более разнообразной. Поэтому, добавляя столько элементов, сколько потребуется, мы так и не решим проблему. Не нужно добавлять новые термины в словарь HTML, надо создать механизм, который позволит придавать документу некий семантический контекст. Формально, нам нужно сделать HTML расширяемым. HTML 5 же не предлагает никаких механизмов расширения.

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

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

Почему бы не взять существующий словарь терминов, например Docbook? Его словарь намного более разнообразен, и разрабатывался специалистами в издательской деятельности на протяжении многи лет. Это не аргумент в поддержку Docbook, суть в том, что чрезвычайно важная задача создания семантических механизмов в HTML решается такими непродуманными методами, почти не учитывая накопленный за последние 30 лет опыт разработок в этой области. (Разработка GML началась в 1970-х годах.)

Мысли по поводу решения

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

Если добавление новых элементов не поможет делу, по крайней мере, в рамках нашей дискуссии, стоит обратить внимание на атрибуты HTML. В конце концов, мы уже лет десять используем class и id для расширения семантики HTML. Множество разработчиков знакомы с такой практикой и полностью удовлетворены ей. Проект microformats показал, что существующих атрибутов HTML в общем недостаточно для расширения семантики. Поэтому, если мы хотим решить проблему с помощью атрибутов, придётся использовать один или несколько новых атрибутов. Перед тем как понять, как это может работать, стоит подумать о уже упомянутых ограничениях. Главное — будут ли новые атрибуты обратно совместимы? И если да, то могут ли они предложить рабочий механизм для расширения семантики HTML?

Давайте придумаем новый атрибут. Я назову его «structure», хотя имя не так важно. Мы можем использовать такую конструкцию:


Посмотрим, как с этим справятся браузеры.

Конечно, во всех браузерах к этому элементу можно применить стили:

div {color: red}

Но как насчёт такого?

div[structure] {font-weight: bold}>

На самом деле, почти все браузеры, включая IE7, позволяют это сделать, даже если атрибута structure нет в HTML! К сожалению, затем удача нам изменяет — IE6 так не умеет. Тем не менее, мы можем использовать этот атрибут — все существующие браузеры его распознают, а все современные браузеры позволят добавлять для него стили. Если же необходимо обеспечить поддержку старых браузеров, в таблице стилей можно использовать атрибут class. Сравните это с решением, предлагаемым HTML 5, в котором к новым тегам невозможно применять стили в Internet Explorer 6 и 7. Теперь вы видите, что оно обратно совместимо в гораздо меньшей степени.

Расширяемость с помощью атрибутов

Вместо новых тегов, в HTML 5 должны быть введены новые атрибуты. Каждый из этих атрибутов будет относиться к определённой семантической категории. HTML, как я подробно рассказывал в другой статье, включает в себя структурную семантику, риторическую семантику, ролевую (как в XHTML) и другие.

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

Это весьма похоже на атрибут role в XHTML, однако вместо единой «связки» для всех семантических элементов, мы должны определить отдельные атрибуты применительно к каждой семантической категории.

К примеру, атрибут role в XHTML используется таким образом:

  • Загрузки
  • Документация
  • Новости

Значением атрибута role является список слов, разделённых пробелом, и взятых из стандартной или определённой пользователем терминологии.

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

Он замечательный человек.

Здесь использован теоретически возможный атрибут «rhetoric», который может быть использован для разметки риторического смысла документа. Очевидно, что элемент, к которому он применён, не играет роли «ирония», хотя его содержимое и является ироничным.

Вот другой пример. Совершенно очевидно, что в HTML не хватает способа привязки машино-читаемого описания к понятному человеку значению, например, к дате. Именно это послужило поводом к отказу BBC от микроформата hCalendar, о чём я уже говорил ранее. Следующий код:

Первое мая  

не имеет смысла, но что-то вроде такого:

Первое мая

вполне применимо.

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

Я назвал этот подраздел «Мысли по поводу решения», поскольку впереди ещё огромное количество работы, и есть множество вопросов, остающихся открытыми:

— Сколько различных семантических атрибутов должно быть? Должны ли эти категории быть расширяемыми, и если да, то как?
— Как будут определяться словари терминов?
— Будем ли мы просто придумывать необходимые термины, как при использовании значений класса, или же возможные значения должны быть стандартизированы спецификацией? Должен ли существовать механизм добавления (и коллективного использования) пользовательских словарей, используя что-то вроде профилей?
— Если два словаря будут конфликтовать между собой, к примеру, при совпадении терминов, как может быть разрешена такая ситуация?
— Нужен ли нам механизм пространств имён, или нечто подобное?

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

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

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

phpbuilder.ru

Что такое семантические элементы?

Семантические элементы четко описывают, что они означают, как браузеру, так и веб-разработчику.

В качестве примера не семантических элементов можно привести теги <div> и <span>. Они ничего не говорят о характере их контента.

Примеры семантических элементов: <form>, <table> и <article>. Они четко описывают, какого характера контент они содержат.

Семантические элементы HTML5 поддерживаются всеми современными браузерами.

Кроме этого, можно «научить» старые браузеры понимать «неизвестные элементы». См. раздел «Поддержка элементов HTML5».

Новые семантические элементы в HTML5

На многих веб-сайтах есть HTML код вроде этого: <div id=»nav»>, <div class=»header»>, <div id=»footer»>. Обычно он используется для выделения блоков навигации, шапки и подвала страницы.

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

Элемент <section>

Элемент <section> определяет раздел в документе.

В соответствии со спецификацией W3C по HTML5: «Раздел — это тематически сгруппированный контент, как правило с заголовком.»

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

Пример:

 <section>  <h1>WWF</h1>  <p>Всемирный фонд дикой природы (WWF) это....</p> </section>  

Элемент <article>

Элемент <article> определяет независимый, самодостаточный контент.

Контент, помещенный в этот элемент, должен иметь смысл сам по себе, т. е. он должен быть понятен в отрыве от остальных частей веб-сайта.

В качестве примеров использования элемента <article> могут выступать:

  • Публикация на форуме
  • Публикация в блоге
  • Газетная статья

Пример:

 <article>  <h1>Что делает Всемирный фонд дикой природы?</h1>  <p>Задача Всемирного фонда дикой природы остановить деградацию окружающей среды  на нашей планете и построить будущее, в котором человечество будет жить в гармонии с  дикой природой.</p> </article>   

Элемент <article> должен быть вложен в <section> или наоборот?

Элемент <article> определяет независимый, самодостаточный контент.

Элемент <section> определяет раздел в документе.

Можно ли по определению сказать, какой из этих элементов в какой должен быть вложен? Нет, нельзя!

В интернете вы найдете HTML страницы с элементами <section>, содержащие элементы <article>, и элементы <article>, содержащие элементы <sections>.

Также, вы встретите страницы с элементами <section>, содержащие другие элементы <section>, и элементы <article>, содержащие другие элементы <article>.

Пример для газеты: Спортивная статья в спортивном разделе может содержать технический раздел.

Элемент <header>

Элемент <header> предназначен для определения заголовочного блока или «шапки» документа или раздела.

Элемент <header> следует использовать как контейнер для вводной информации.

В одном документе разрешается определять несколько элементов <header>.

В следующем примере определяется «шапка» для статьи:

 <article>  <header>  <h1>Что делает Всемирный фонд дикой природы (ВФП)?</h1>  <p>Цель ВФП:</p>  </header>  <p>Задача Всемирного фонда дикой природы остановить деградацию окружающей среды  на нашей планете и построить будущее, в котором человечество будет жить в гармонии с  дикой природой.</p> </article>  

Элемент <footer>

Элемент <footer> предназначен для определения «подвала» документа или раздела.

Элемент <footer> должен содержать информацию о содержащим его элементе.

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

В одном документе разрешается определять несколько элементов <footer>.

Пример:

 <footer>  <p>Автор И.И.Иванов</p>  <p>Контактная информация: <a href="mailto:someone@example.com">someone@example.com</a>.</p> </footer>  

Элемент <nav>

Элемент <nav> определяет набор ссылок навигации.

Обратите внимание, что НЕ ВСЕ ссылки в документе следует размещать внутри элемента <nav>. Элемент <nav> предназначен только для основного блока навигационных ссылок.

Пример

 <nav>  <a href='/html/'>HTML</a> |  <a href='/css/'>CSS</a> |  <a href='/js/'>JavaScript</a> |  <a href='/jquery/'>jQuery</a> </nav>  

Элемент <aside>

Элемент <aside> определяет некий контент, находящийся в стороне от контента, внутри которого он расположен (как боковой блок страницы, «сайдбар»).

Контент внутри элемента <aside> должен соотноситься с окружающим контентом.

Пример

 <p>Этим летом я с семьей посетил EPCOT центр.</p>  <aside>  <h4>EPCOT центр</h4>  <p> EPCOT центр — это тематический парк в развлекательном комплексе Уолта Диснея во Флориде.</p> </aside>  

Элементы <figure> и <figcaption>

Назначение элемента <figcaption> — добавление визуального пояснения к изображению.

В HTML5 изображение и пояснение к нему может быть сгруппировано в элементе <figure>:

 <figure>  <img src='img_pulpit.jpg' alt="The Pulpit Rock" width="304" height="228">  <figcaption>Рис. 1 — Палпит Рок. Гора в Норвегии</figcaption> </figure>  

Элемент <img> определяет изображение, а элемент <figcaption> пояснение к нему.

Зачем нужны семантические элементы?

В HTML4 веб-разработчики использовали свои собственные имена в идентификаторах/классах элементов для их стилизации: header, top, bottom, footer, menu, navigation, main, container, content, article, sidebar, topnav и т.п.

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

Благодаря новым элементам HTML5 (<header>, <footer>, <nav>, <section>, <article>), сделать это стало гораздо проще.

msiter.ru

HTML5 | Семантическая разметка сайта

Что такое семантика в HTML

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

Семантическая вёрстка веб-документа

Семантическая вёрстка веб-страницы или семантический код HTML-документа – это вёрстка с правильным использования HTML-тегов в соответствии с их предназначением (семантикой). Кроме этого, семантическая вёрстка предполагает логичную и последовательную иерархию для построения всей веб-страницы, в соответствии с законами HTML-документа.

Чем отличается семантическая вёрстка от обычной
Семантическая вёрстка веб-документа противопоставляется обычной, при котором написание HTML-кода определяется только внешним видом веб-страницы. При семантической вёрстке, ряд элементов страницы имеют свои собственные теги, которые прямо отображают их назначение. Это и есть «семантика» в HTML. Так, например, структура простейшей веб-страницы при обычной вёрстке может выглядеть так:
<div class=»header»>Шапка сайта</div>
<div class=»navigasia»>Главное верхнее меню сайта</div>
<div class=»sidebar»>Дополнительное боковое сайта</div>
<div class=»content»>Содержимое веб-страницы</div>
<div class=»footer»>Подвал сайта</div>
Тогда, как при семантической вёрстке, структура той же самой веб-страницы будет иметь вид:
<header>Шапка сайта</header>
<nav> Главное верхнее меню сайта </nav>
<aside>Дополнительное боковое сайта</aside>
<article>Содержимое веб-страницы</article >
<footer>Подвал сайта</footer>
Как видно из примера, для обозначения и задания соответствующих стандартных элементов веб-страницы использованы соответствующие теги. Кроме этого, код гораздо проще. При этом, внешний вид такой страницы для человеческого глаза – останется абсолютно неизменным. Возникает резонный вопрос – а зачем тогда нужна семантическая вёрстка и разметка веб-страницы, если людям она не видна?

Зачем нужна семантическая вёрстка

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

Семантическая вёрстка в HTML5

Полный фурор и переворот понятия веб-семантики произошёл с появлением HTML5.

В HTML4 всё было довольно просто. Для оформления веб-страниц, написанных в соответствии с семантикой, достаточно было использовать внешние каскадные таблицы стилей (CSS) да пару нехитрых нововведений, вида замены тегов <i> и <b> на <em> и <strong>. HTML5 – не в пример «семантичней» и это видно из приведённого примера.

Новые популярные семантические теги HTML5

Прежде всего, <!DOCTYPE html> – простой и понятный всем доктайп.

Дальше идут теги, определяющие семантическую специализацию блоков:
(семантические теги)

<article> <aside> <audio> <canvas> <command> <datalist> <details> <figcaption> <figure> <footer><header> <hgroup> <keygen> <main> <mark> <menu> <meter> <nav> <output> <progress> <rp><rt> <ruby> <section> <source> <summary> <time> <video> <wbr>

Проблемы совместимости HTML5 и XHTML

Принципиально, в совместимости HTML5 и XHTML – проблем нет никаких. Все новые браузеры прекрасно поддерживают теги HTML5 и выполняют их. Единственное огорчение ждёт любителей валидного кода. Потому что, большинство сайтов свёрстано не HTML, а в XHTML. И теперь, получается странная ситуация – доктайп от XHTML, а теги из HTML5. Валидатор «вешается и пишет красным». В настоящий момент, на такую «нестыковку» все закрыли глаза. А что делать? Ведь XHTML всегда был только производным языком от HTML.

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

Плавный переход шаблона с XHTML на HTML5

Как утверждают специалисты, HTML5 – это не одна большая вещь, это набор разных возможностей. Поэтому, начинать переходить с XHTML на HTML5 можно постепенно, по частям добавляя нужный код в свой шаблон. Валидатор XHTML ругнётся и всё вскорости образуется. Ведь всем остальным – «по барабану», теги HTML5 работают везде и вся. Для начала, можно изменить общую структуру своего шаблона, простой заменой классов CSS на семантические теги из примера «Чем отличается семантическая вёрстка от обычной».

HTML5 | Семантическая разметка сайта

(Главное – начать)
Опять-же таки, как утверждают известные специалисты – «обновление» до HTML5 можно сделать простым изменением доктайпа. Элемент <!DOCTYPE> в HTML5 имеет предельно простой вид: <!DOCTYPE html>. После такого «обновления», ровным счётом ничего не произойдёт, потому что все теги, определённые в HTML4, также поддерживаются и в HTML5. Что касаемо перехода с XHTML на HTML5, то тут я не рискнул на своём сайте так резко менять <!DOCTYPE>, решился только на постепенную замену части тегов да изменение структуры страницы.

 

tehnopost.info

Семантическая структура для HTML5 страницы

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

 

DOCTYPE и meta теги в заголовке страницы

Начнем со стандартного шаблона HTML5 документа, и добавим теги meta в head:

<!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <title>Заголовок страницы</title>     <meta name="keywords" content="Ключевые слова, и, фразы, через, запятую">     <meta name="description" content="Описание контента страницы, 1-2 предложения."> </head> <body>

Я добавил тег <meta name="keywords" content=""> который отвечает за ключевые слова. И тег <meta name="description" content=""> который отвечает за описание страницы. Для SEO оптимизации эти теги обязательны. Также обязательно корректное заполнение тега <title>. Title страницы должен быть уникальным для всего сайта, и содержать в названии всю суть страницы для которой он указан.

Пойдем дальше. В HTML5 появились новые теги, которые используются для того чтобы делать семантическую разметку документа. Это теги header, nav, main, article, aside, footer и т.д. По отображению они работают также как и обычные <div> теги, то есть это блочные элементы. Но если <div> не имеет семантической нагрузки, то header, nav, main и другие — уже нужно использовать только осмысленно.

 

Заголовок страницы

Шапка страницы оформляется в тег header. Заметьте что заголовок страницы пишем тегом h1.

<!-- Header страницы -->     <header>             <h1>Site title</h1>     </header>

Если у нас есть еще и слоган рядом с заголовком, то помещаем его в p, div или span.

<!-- Header страницы -->     <header>             <h1>Site title</h1>             <p>site slogan</p>     </header>

Замечание по поводу тега H1

Следует заметить что в HTML5 тег H1 используется для указания заголовка контейнера в котором он находится (это может быть header, section, article и т.д.)

До появления HTML5 тегов семантика была несколько другой и отличалась. Так в HTML4 на странице мог быть только один заголовок H1! Как правило это был заголовок статьи или заголовок страницы (например если это страница рубрики на которой отображаются несколько статей.) H2 использовался для подзаголовков, или для разделов главной статьи. H3 для под разделов и так далее.

 

Навигация на странице

Оформление главной навигации по сайту должно заключаться в тег nav. Также следует помнить что хорошей практикой считается оформлять навигацию элементами списка.

<!-- Главная Навигация по сайту -->     <nav>         <ul>             <li><a href="#">Home</a></li>             <li><a href="#">Portfolio</a></li>             <li><a href="#">Gallery</a></li>             <li><a href="#">Contacts</a></li>         </ul>     </nav>

 

Контент на странице

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

<!-- Основное содержимое страниц --> <main>          ...основной контент страницы...  </main>

 

Оформление статьи

Тег article — служит для обертки статей. В общем этот тег содержит в себе блок контента, который может быть вынут из контекста страницы, и использован отдельно в другом месте. Это может быть статья (полный тескт статьи или превью), пост на форуме, и т.п.

На примере ниже я показал оформление статьи в контексте, внутри тега main. У статьи задан блок header с заголовком статьи. Дата публикации статьи задана специальным тегом time, который отображается как обычный inline элемент. У тега time есть специальный аттрибут в котором время публикации должно быть задано в машинном формате. Это может быть только дата datetime="2015-09-30" или с указанием часов минут и секунд datetime="2015-09-30T15:25:55". Параметр pubdate указывает что статья была и опубликована в то же время что и написана. Если это новость, то может быть такое что время новости одно, а время публикации другое, для этого необходимо указать два раза тег time, и поставить pubdate только в том теге где указано время публикации.

<main> ... <!-- Статья -->     <article>          <!-- Шапка статьи если в шапке у нас больше чем заголовок -->         <header>                      <!-- Заголовок статьи -->             <h1>Article title</h1>                          <!-- Дата публикации статьи  -->             <time datetime="2015-09-30T15:25:55" pubdate>30 Сентября</time>                      </header>          <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Nemo quisquam, soluta sunt, aliquam voluptatem voluptates! Deserunt repudiandae aperiam pariatur sit harum at a, quo, est neque. Adipisci beatae eaque unde?</p>          <!-- Подзаголовок страницы -->         <h2>Article sub-title</h2>          <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Nemo quisquam, soluta sunt, aliquam voluptatem voluptates! Deserunt repudiandae aperiam pariatur sit harum at a, quo, est neque. Adipisci beatae eaque unde?</p>                  <footer>             <a href="#">Читать далее</a>             <a href="#">Комментарии</a>         </footer>      </article> ... </main>

Из примера выше видна что внутри статьи были использованы теги header и footer чтобы выделить заголовок и нижний колонтитул статьи.

 

Сайдбар или колонка с виджетами

Для каждого отдельного элемента сайдбара используем блок aside. Внутри него заголовок оформляем тегом h1. Так колонка с сайдбаром может выглядеть следующим образом:

<!-- Сайдбар --> <div class="sidebar">          <!-- Виджет в сайдбаре -->         <aside>             <h1>Widget title</h1>             ...         </aside>          <!-- Виджет в сайдбаре -->         <aside>             <h1>Последние записи</h1>             ...         </aside>           <!-- Виджет в сайдбаре -->         <aside>             <h1>Популярные комментарии</h1>             ...         </aside>          </div>

 

Тег section

Тег section — используется для представления группы или секции тематически связанного контента.Его использование похоже на article с главным отличием в том что допускается отсутствие смысла содержимого внутри элемента <section> вне контекста самой страницы. Рекомендуется использовать теги (<h1> – <h6>) для обозначения темы секции.

В качестве примера можно привести статью, которую вы сейчас читаете, можно было бы каждый параграф обернуть в тег <section>. Например тегом section можно выделять блоки контента на лендинге. Звучит похоже на определение div элемента, который часто используется как контейнер для контента. Разница в том что div не имеет семантического значения, и он не говорит не о чем про контент находящийся внутри него. Тег section, наоборот используется чтобы четко показать что контент внутри него связан по смыслу. Вы можете заменить некоторые свои div теги на section, но всегда отвечайте себе на вопрос: «Этот контент связан между собой или нет?»

Пример использования тега section в списке с перечислением городов:

<h1>An Event Apart</h1>  <section>      <header>         <h2>Cities</h2>     </header>     <p>Join us in these cities in 2010.</p>       <section>         <header>             <h3>Seattle</h3>         </header>         <p>Follow the yellow brick road.</p>     </section>      <section>         <header>             <h3>Boston</h3>         </header>         <p>That's Beantown to its friends.</p>     </section>      <section>         <header>             <h3>Minneapolis</h3>         </header>         <p>It's so <em>nice</em>.</p>     </section>  </section>  <small>Accommodation not provided.</small>

 

Подвал сайта — Footer

Подвал сайта оформляется тегом <footer>

<!-- Подвал сайта --> <footer>         <p class="copyright">© 2015 Rightblog.ru Copyright</p> </footer>

 

Заключение

Для проверки структуры страницы можно использовать инструмент HTML5 outliner. Он показывает структуру страницы блокам и заголовкам.

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

В продолжение темы можно изучить другие новые HTML5 теги. А также микро форматы для оформления и структуризации данных, например такие как schema.org

 

Важное замечание по использованию HTML5 тегов. В спецификации не указаны жесткие правила по использованию семантических тегов, указаны лишь рекомендации п их использованию. Если вы не понимаете или не знаете где и какой HTML5 тег использовать, лучше используйте div — чтобы не навредить и не нарушить структуру документа.

 

Статьи и материалы по теме:
http://html5forwebdesigners.com/semantics/
http://habrahabr.ru/post/214407/
http://www.adobe.com/devnet/archive/dreamweaver/articles/understanding-html5-semantics.html
http://www.smashingmagazine.com/2011/11/html5-semantics/
http://blogs.msdn.com/b/jennifer/archive/2011/08/01/html5-part-1-semantic-markup-and-page-layout.aspx
http://www.w3schools.com/html/html5_semantic_elements.asp

rightblog.ru

You May Also Like

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

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

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.