Семантика html


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

Стандарт HTML5 предоставил новые элементы для структурирования, группировки контента и разметки текстового содержимого. Новые семантические элементы позволили улучшить структуру веб-страницы, добавив смысловое значение заключенному в них содержимому (было <div id="header">, стало <header>). Для отображения внешнего вида элементов не задано никаких правил, поэтому элементы можно стилизовать по своему усмотрению. Для всех элементов доступны ‎глобальные атрибуты.

Согласно спецификации HTML5 каждый элемент принадлежит к определенной (ноль или более) категории. Каждая из них группирует элементы со схожими характеристиками. Выделяют следующие общие категории:


  • Мета содержимое
  • Потоковое содержимое
  • Секционное содержимое
  • Заголовочное содержимое
  • Текстовое содержимое
  • Встроенное содержимое
  • Интерактивное содержимое

Описание HTML5-элементов

  • Содержание:
  • 1. Элемент <header>
  • 2. Элемент <nav>
  • 3. Элемент <article>
  • 4. Элемент <section>
  • 5. Элемент <aside>
  • 6. Элемент <footer>
  • 7. Элемент <address>
  • 8. Элемент <main>
  • 9. Элемент <figure>
  • 10. Элемент <figcaption>
  • 11. Элемент <time>
  • 12. Элемент <mark>
  • 13. Элемент <bdi>
  • 14. Элемент <wbr>
  • 15. Элементы для описания Восточно-Азиатских символов

1. Элемент <header>

Категории контента: потоковое содержимое.
Группирует вводные и навигационные элементы, не является обязательным. Может содержать заголовки, оборачивать содержание раздела страницы, форму поиска или логотип. В HTML-документе может содержаться одновременно несколько элементов <header> и они могут располагаться в любой части страницы.


<header>   <h1>Site description</h1>   <nav>   <ul>   <li><a href="">About</a>   <li><a href="">Forum</a>   <li><a href="">Download</a>   </ul>   </nav>  </header>

Элемент <header> нельзя помещать внутрь элементов <footer>, <address> или другого элемента <header>.

2. Элемент <nav>

Категории контента: потоковое содержимое, секционное содержимое.
Предназначен для создания блока навигации веб-страницы или всего веб-сайта, при этом не обязательно должен находиться внутри <header>. На странице может быть несколько элементов <nav>. Не заменяет теги <ul> или <оl>, он просто их обрамляет. Не все группы ссылок на странице должны быть обёрнуты <nav>, этот элемент предназначен в первую очередь для разделов, которые состоят из главных навигационных блоков.

<nav>   <ul>   <li><a>...</a></li>   <li><a>...</a></li>   <li><a>...</a></li>   </ul>  </nav>

В качестве элементов панели навигации можно использовать не только элементы списков:


<nav>   <p><a href="">...</a></p>   <p><a href="">...</a></p>  </nav>

Также можно добавлять заголовки внутрь элемента:

<nav>   <h2>...</h2>   <ul>   <li><a>...</a></li>   <li><a>...</a></li>   <li><a>...</a></li>   </ul>  </nav>

3. Элемент <article>

Категории контента: потоковое содержимое, секционное содержимое.
Используется для группировки записей — публикаций, статей, записей блога, комментариев. Представляет собой независимый обособленный блок, предназначенный для многократного использования, как правило, начинается с заголовка. Может дублироваться на других страницах сайта и содержать внутри другие элементы <article>, которые по содержанию имеют близкое отношение к содержанию внешней статьи. Если на странице присутствует только одна статья с заголовком и текстовым содержимым, она не нуждается в обёртке элементом <article>. Элемент рекомендуется использовать только в том случае, если содержимое элемента будет явно указано в схеме документа.


<article>   <header>   <h2>...</h2>   </header>   <p>...</p>   <footer>   Опубликовано в категории<a href="">Музыка</a>.   <a href="">0 комментариев</a>   </footer>  </article>

4. Элемент <section>

Категории контента: потоковое содержимое, секционное содержимое.
Элемент представляет собой универсальный раздел документа. Группирует тематическое содержимое и обычно содержит заголовок. Не является блоком-оберткой, для этих целей уместнее использовать элемент <div>. В качестве содержимого может выступать оглавление, разделы научных публикаций, программа мероприятия. Домашняя страница сайта также может быть поделена на секции — блок вводной информации, новости и контакты. Элемент рекомендуется использовать только в том случае, если содержимое элемента будет явно указано в схеме документа.

<article>   <h1>...</h1>   <section>   <h2>...</h2>   <p>...</p>   </section>   <section>   <h2>...</h2>   <p>...</p>   </section>   <p>...</p>  </article>

<article> внутри <section>

Можно создавать родительские элементы <section> с вложенными элементами <article>, в которых есть один или несколько элементов <article>. Не все страницы должны быть устроены именно так, но это допустимый способ вложения элементов. Например, основная область контента страницы содержит два блока со статьями разной тематики. Можно сделать на этом акцент, поместив каждую статью одной тематики внутрь элемента <section>


<section>   <h1>Заметки о природе</h1>   <article>   <h2>...</h2>   <p>...</p>   </article>   <article>   <h2>...</h2>   <p>...</p>   </article>  </section>  <section>   <h1>Исторические заметки</h1>   <article>   <h2>...</h2>   <p>...</p>   </article>   <article>   <h2>...</h2>   <p>...</p>   </article>  </section>

5. Элемент <aside>

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

<aside>   <h2>...</h2>   <p>...</p>  </aside>

<aside>   <h2>...</h2>   <p>...</p>   <blockquote>   <p>...<cite>...</cite>...</p>   <p>...</p>   </blockquote>  </aside>

6. Элемент <footer>

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

В одном веб-документе может быть несколько элементов <footer>. Как каждая страница, так и каждая статья может иметь свой элемент <footer>, более того, <footer> можно поместить в элемент <blockquote>, чтобы указать источник цитирования.

<footer>   <address>...</address>   <small>@2014...</small>  </footer>

7. Элемент <address>

Категории контента: потоковое содержимое.
Используется для определения контактной информации автора/владельца документа или статьи. Для обозначения автора документа тег размещают внутри элемента <body>, для отображения автора статьи — внутри тега <article>. В браузере обычно отображается курсивом.


8. Элемент <main>

Категории контента: потоковое содержимое.
Элемент <main> представляет основное содержимое документа (содержимое элемента <body>). Контент, находящийся внутри элемента, должен быть уникальным и не повторяться во всех документах сайта, таких как навигационные ссылки, информация о копирайте, логотипы, формы поиска (в случае, если форма поиска является основной функцией документа).

Элемент <main> не может быть потомком таких элементов как <article>, <aside>, <footer>, <header> или <nav>.

<body>  <header>   <h1>Пудель</h1>   <nav>   <ul>   <li><a href="index.html">Главная</a></li>   <li><a href="about.html">О породе</a></li>   <li><a href="health.html">Здоровье</a></li>   </ul>   </nav>   </header>   <main>   <section>   <header>   <h2>О породе</h2>   <nav>   <ul>   <li><a href="#basic">Разновидности</a></li>   <li><a href="#app">Внешний вид<.  

ости</a> <a href="#app">Внешний вид</a> <a href="#temp">Характер</a> </footer> </section> </main> <footer> <small>Copyright © <time datetime="2016">2016</time> Моя собака.ру</small> </footer> </body>

9. Элемент <figure>

Категории контента: потоковое содержимое, корневое секционное содержимое.
Элемент <figure> представляет автономный контент (необязательно с заголовком), являющийся самостоятельным элементом основного потока. Элемент может быть перемещен из основного содержимого документа в боковую колонку или приложение, не затрагивая поток документа. С помощью элемента <figure> можно добавлять краткие характеристики к иллюстрациям, фотографиям, диаграммам, фрагментам кода и т.д..

<figure>   <img src="picture.jpg" alt="Осень">   <figcaption>Осенний лес</figcaption>  </figure>

Элемент <figure> является блочным, по ширине занимает всю ширину блока-контейнера за минусом внешних отступов margin:


margin-left: 40px;  margin-right: 40px;  margin-top: 1em;  margin-bottom: 1em;

10. Элемент <figcaption>

Элемент <figcaption> — потомок элемента <figure>, не принадлежит ни к одной категории контента. Элемент является блочным, по ширине равен ширине элемента <figure>, высота по умолчанию равна 18px.

11. Элемент <time>

Категории контента: потоковое содержимое, текстовое содержимое.
Определяет время (24 часа) или дату по григорианскому календарю с возможным указанием времени и смещения часового пояса. Текст, заключенный в данный тег, не имеет стилевого оформления браузером. Для тега доступен атрибут datetime, в качестве содержимого которого указывается то, что будет видеть пользователь на экране своего компьютера:

<time datetime="2014-09-25"> 25 Сентября 2014</time>

Чтобы дата могла считываться автоматически, она должна быть в формате YYYY-MM-DD. Время, которое также может указываться, задается в формате HH:MM с добавлением разделяющего префикса T (time):

<time datetime="2014-09-25T12:00"> 25 Сентября 2014</time>

12. Элемент <mark>

Категории контента: потоковое содержимое, текстовое содержимое.
Текст, помещенный внутрь тега <mark>, выделяется по умолчанию желтым цветом (цвет фона и цвет шрифта в выделенном блоке можно изменить, задав определенные css-стили). С помощью данного тега можно отмечать важное содержимое, а также ключевые слова.


13. Элемент <bdi>

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

14. Элемент <wbr>

Категории контента: потоковое содержимое, текстовое содержимое.
Одиночный тег, показывает браузеру место, где можно добавить разрыв длинной строки в случае необходимости.

15. Элементы для описания Восточно-Азиатских символов

Категории контента: потоковое содержимое, текстовое содержимое.
Элемент <ruby> позволяет помечать один и более элементов категории текстовое содержимое с помощью ruby-аннотации. Ruby-аннотация используется в преимущественно в Восточно-Азиатской типографики как руководство по произношению или для включения других характеристик. Элемент может содержать:
— один и более текстовых узлов или элементов <rb>;
— один и более элементов <rt>, <rtc>, каждый из которых предшествует или следует непосредственно за элементом <rp>.

Элементы <rb>, <rt>, <rtc> и <rp> не относятся ни к одной категории контента.

Элемент <rb> определяет вложенный в него текст как базовый компонент аннотации.
Элемент <rt> выводит аннотацию к тексту сверху или снизу над ним.
Элемент <rtc> отмечает вложенный в него текст как дополнительную аннотацию.
Элемент <rp> выводит альтернативный текст в случае если браузер не поддерживает элемент <ruby>.

html5book.ru

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

Семантика в языкознании означает смысл, значение слова или речевого оборота. Мы уже встречали данный термин, когда рассматривали сбор семантического ядра для сайта. И в том контексте, и в сегодняшней статье определение «семантический» указывает на то, что в основе лежит смысл. А стало быть, семантическая верстка – это верстка, построенная на смысловой структуре. В отличие от так называемой верстки на дивах (div – html-тег), все элементы семантической верстки подчинены смысловой иерархии. И самый наглядный пример для объяснения – это использование тегов заголовков и подзаголовков h1, h2, h3 и т.д.Семантическая разметка страницы

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

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

Когда каждому структурному элементу сайта соответствует определенный тег, код становится упорядоченным и понятным. При этом описание стилей элементов выводятся в отдельный css-файл. Для того, чтобы увидеть насколько страницы вашего сайта структурированы можно проделать простой эксперимент. Отключите на время в браузере поддержку CSS и JavaScript и посмотрите, где на вашем ресурсе названия статей, содержание, подзаголовки и т.д. Можете ли вы разобраться в структуре вашего сайта, используя только html-разметку?

Примеры семантической верстки HTML5

Еще один наглядный пример, где ясно видно отличие семантической верстки от прошлых стандартов html, — использование тега <em> (от английского emphasis – акцент). Тег <em> заменил тег <i> (выделение курсивом). Для тега <em> в файле стилей может задаваться отображение курсивом, подчеркиванием, полужирным. Но значение данного тега – именно акцентирование текста, к примеру, для выделения нового термина. Однако, в случае, когда нужно употребить цитату, в семантической верстке будет уже использоваться тег <cite>, хотя ранее оба эти элемента (и новый термин, и цитата) были бы заключены в тег <i> (выделены курсивом).

А теперь приведем пример, как верстка дивами заменяется семантической.

Пример обычной верстки:

Замена на семантическую:

Здесь мы использовали теги семантической верстки: section, article, h1, p.

Стили прописываются, как правило, в отдельном в файле (в случае с WordPress в style.css) следующим образом:

В случае верстки с div, данное описание выглядело бы так:

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

Распространенные теги HTML5 для семантической верстки

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

<header> — задает шапку сайта или раздела, в него обычно включен заголовок, а также внутрь могут помещаться другие теги, кроме более высоких по иерархии (html, body, head и т.п.)

<article> — тег, в который заключают элементы статьи: непосредственно текст, изображения, комментарии

<section> — разделяет веб-документ на смысловые секции, есть возможность вкладывать один тег section в другой

<footer> — подвал сайта, где содержится информация о контактах, адреса, ссылки, авторство и прочее

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

<aside> — блок неосновного контента, как правило, боковая панель (сайдбар): рекламные блоки, рубрики, метки и т.д.

Теперь, зная вышеприведенные теги, посмотрим, как они работают на примере ниже.

Прописываем такой код в редакторе Notepad или Блокноте:

Теперь запустим документ, как html-файл.

Далее нам необходимо задать стили для каждого элемента. В нашем случае, добавим тег <style> с описаниями в уже созданный html-файл. Если же вы вносите изменения на сайте на WordPress, добавляйте правки в файл стиле style.css.

Итак, общий вид нашего файла style.css будет таким:

Подробно изучив приведенный код, вы увидите, что для каждого тега (header, section, article, footer) заданы расположение, ширина, цвет заливки или шрифта.

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

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

  • <video> — воспроизведение и управление видео;
  • <audio> — добавление и управление аудио на странице;
  • <canvas> — область для создания изображений и других объектов Javascript;
  • <command> — кнопка или переключатель внутри тега <menu>;
  • <menu> — создание меню и контейнер для тега <command>;
  • <datalist> — список вариантов, доступный после ввода в текстовом поле (пример такого списка – подсказки Google);
  • <figure> — группирование элементов (например, изображения с подписями);
  • <hgroup> — группирование заголовков и подзаголовков;
  • <mark> — смысловое выделение текста;
  • <meter> — вывод значений в заданном диапазоне, как правило, числовые данные;
  • <ruby> — добавление аннотации сверху или снизу основного текста (пример – транскрипция под словами);
  • <source> — вставка аудио- или видеофайла внутри тегов audio, video;
  • <time> — текст внутри тега приобретает значение даты, времени;

Напоследок, смотрите познавательный видео-урок по основам html5, его тегами и примерами их использования:

При должной устремленности, вы обязательно сможете освоить необходимые  знания. Верьте в свои силы.

До новых встреч!

pro-wordpress.ru

Но…

Допустим, что у вас на сайте есть две статьи. И вы желаете задать им разные стили. «Обзоры фильмов» будут иметь голубой фон, а «Горячие новости» — красный фон и шрифт большего размера.

Один из способов решить задачу такой:

Другой способ такой:

Наверняка, если опросить нескольких разработчиков о том, какой код более соответствует требованиям семантики, большинство укажет на первый вариант. Он отлично соответствует материалу данного урока: описание назначение без ссылок на форматирование. А второй вариант указывает на формат («blueBg» — имя класса, которое сформировано из двух английских слов, означающих «голубой фон»). Если вдруг будет принято решение поменять дизайн обзоров фильмов — например, сделать зеленый фон, то имя класса «blueBg» превратится в кошмар разработчика. А имя «movie-review» позволит абсолютно спокойно изменять стили оформления с сохранением отличного уровня поддержки кода.

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

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

Такой стиль помогает сохранять CSS файл более организованным (разные области определяются в разных разделах). Но платой является повторение определений. Для больших сайтов определение одного и того же цвета может доходить до нескольких тысяч раз. Ужасно! Вариантом решения может быть использование класса по типу «blueBg» для определения цвета один раз и вставки его в HTML коде, когда требуется использовать данный дизайн. Конечно, его лучше назвать «mainBrandColor» или «secondaryFont», чтобы отвязаться от описания форматирования. Можно пожертвовать семантикой кода в пользу сохранения ресурсов.

ruseller.com

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

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

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

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

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

Итак, как HTML 5 решит этот вопрос? HTML 5 вводит ряд новых элементов. Некоторые я назвал «структурные» — section, nav, aside, header и footer. Элемент dialog который по типу и содержанию схож с blockquote. Есть так же целый ряд элементов данных, как например meter, который представляет собой «скалярное измерение в пределах известного диапазона или дробное значение, например использование диска»; и элемент time{http://www.w3.org/html/wg/html5/#the-time}, который представляет собой дату и/или время.

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

Рассмотрим каждое препятствие

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

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

<h1>Top Level Heading</h1>
<section>
  <h1>Second Level Heading</h1>
  <p>this is text in a section element</p>
  <section>
  <h1>Third Level Heading</h1>
  </section>
</section>

* This source code was highlighted with Source Code Highlighter.

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

section {color: red}

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

Поэтому у нас есть проблема обратной совместимости с 75% броузеров, использующихся в настоящее время. Учитывая, период полураспад Internet Explorer, мы можем прогнозировать, что большинство пользователей будут использовать IE6 и IE7, даже через несколько лет.

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

Давайте обратимся к совместимости снизу вверх, это следующая проблема.

Совместимость снизу вверх

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

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

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

Остаюнся несколько вопросов о новых элементах. Откуда взяты названия новых элементов? Как было решено, что элемент навигации нужно называть «nav»? Зачем в навигации применяются термины page-level, site-level и meta-site-level?

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

Некоторые идеи решения

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

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

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

<div structure="header">

Давайте посмотрим, как наши броузеры это оценят.

Конечно, все наши броузеры обработают следующий элемент CSS.

div {color: red}

А как насчет этого:

div[structure] {font-weight: bold}

На самом деле, почти все броузеры, включая IE7, обработают стиль div с атрибутом structure, даже если нет такого атрибута. К сожалению, наше счастье изчезает, потому что IE6 нет. Но мы можем использовать этот атрибут в HTML и все существующие броузеры распознают его. Мы даже можем использовать стили CSS для нашего HTML, с использованием атрибута во всех современных броузерах. И если мы хотим обойти старые броузеры, мы можем добавить class, со значением стиля. В сравнении с HTML 5 решением, которое добавляет новые элементы, не работающие в Internet Explorer 6 или 7, мы видим, что это, безусловно, более обратно совместимое решение.

habr.com

Семантическая структура для 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

О семантике

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

Как различать разные типы семантики HTML

Принцип написания "семантичного HTML" — один из столпов современной профессиональной клиентской веб-разработки. Большая часть семантики относится к «природе» имеющегося или ожидаемого контента (напр. элемент h1, атрибут lang, значение email атрибута type или микроданные).

Однако не вся семантика должна быть производной от контента. Имена классов не могут быть «несемантичными». Для чего бы классы ни использовались — у них есть значение, есть цель. Семантика имен классов может отличаться от таковой для HTML-элементов. Мы можем вовсю пользоваться общепринятой «глобальной» семантикой элементов и определенных атрибутов HTML, микроданных и т.п., не путая их задачи с задачами «локальной» семантики, специфичной для данного сайта или приложения, которая обычно заключена в атрибутах типа class.

Несмотря на повторяющееся в разделе спецификации HTML5 о классах допущение о «хорошей практике», согласно которой…

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

…нет ни одной объективной причины так делать. На самом деле, это часто лишь помеха в работе над большими сайтами или приложениями.

  • Контентная семантика уже выражена элементами и другими атрибутами HTML.
  • Имена классов не сообщают почти никакой (или вовсе никакой) смысловой информации ни машинам, ни людям, если только они не входят в ограниченное множество общепринятых (и машиночитаемых) имен — микроформаты.
  • Основное назначение имен классов — привязка для CSS и JavaScript. Если вам не нужно добавлять к веб-документу представление и поведение, вам, вероятно, и классы в HTML не нужны.
  • Имена классов должны передавать полезную информацию разработчикам. Полезно понимать, что делает то или иное имя класса, при чтении фрагмента DOM, особенно в командах из множества разработчиков, где, кроме специалистов по клиентской стороне, с HTML-компонентами могут работать и другие люди.

Возьмем вот такой простейший пример:

<div class="news">   <h2>News</h2>   [контент новости]  </div>

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

Контентно-независимые имена классов

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

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

Архитектура клиентской части

Цель компонентно-/шаблонно-/объектно-ориентированной архитектуры — иметь возможность создать ограниченное число повторно используемых компонентов, которые могут содержать целый диапазон разных типов контента. Важная вещь в семантике имен классов для нетривиальных приложений — они должны диктоваться прагматизмом и наилучшим образом служить своей первоочередной задаче: предоставлять понятные, гибкие и многоразовые презентационные и поведенческие «зацепки» для использования разработчиками.

Компоненты, которые можно использовать повторно и комбинировать

Масштабируемый HTML/CSS должен, вообще говоря, полагаться на классы в HTML, чтобы создаваемые компоненты действительно можно было использовать повторно. Гибкий и многоразовый компонент — это такой, который ни полагается на определенную часть DOM-дерева внутри себя, ни требует элементов определенного типа. Он должен подстраиваться под разные контейнеры и легко менять темы оформления. Если необходимо, для большей надежности компонента можно использовать и дополнительные HTML-элементы, сверх того, что нужно просто для разметки контента. Хороший пример — то, что Николь Салливэн называет медиаобъектом.

Компоненты, которые легко можно комбинировать друг с другом, выигрывают от отказа от селекторов по типу в пользу классов. В следующем примере непросто объединить компоненты btn и uilist. Проблема в том, что специфичность селектора .btn ниже, чем у .uilist a (который перекрывает общие свойства), и в том, что компонент uilist требует, чтобы внутри у него были именно ссылки.

.btn { /* стили */ }  .uilist { /* стили */ }  .uilist a { /* стили */ }
<nav class="uilist">   <a href="#">Домой</a>   <a href="#">О нас</a>   <a class="btn" href="#">Вход</a>  </nav>

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

.btn { /* стили */ }  .uilist { /* стили */ }  .uilist-item { /* стили */ } /* ключевой момент */
<nav class="uilist">   <a class="uilist-item" href="#">Домой</a>   <a class="uilist-item" href="#">О нас</a>   <span class="uilist-item"><!-- обратите внимание на имя тега -->   <a class="btn" href="#">Вход</a>   </span>  </nav>

Классы, связанные с JavaScript

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

<a href="/login" class="btn btn-primary js-login"></a>

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

Модификаторы компонентов

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

«Одноклассовый» паттерн

.btn, .btn-primary { /* стили шаблона кнопки */ }  .btn-primary { /* стили, специфичные для кнопки входа */ }
<button class="btn">Default</button>  <button class="btn-primary">Login</button>

«Многоклассовый» паттерн

.btn { /* стили шаблона кнопки */ }  .btn-primary { /* стили специфичные для основной кнопки */ }
<button class="btn">Default</button>  <button class="btn btn-primary">Login</button>

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

Я пришел к выводу, что он лучше масштабируется. Например, возьмем базовый объект btn и добавим еще 5 типов кнопок и 3 добавочных размера. С «многоклассовым» паттерном вы ограничитесь 9 классами, которые можно будет смешивать и комбинировать. С «одноклассовым» вам понадобятся 24 класса.

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

/* "многоклассовая" подстройка */  .thing .btn { /* правки стилей */ }    /* "одноклассовая" подстройка */  .thing .btn,  .thing .btn-primary,  .thing .btn-danger,  .thing .btn-etc { /* правки стилей */ }

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

Структурированные имена классов

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

Отследить связь между btn (компонентом), btn-primary (модификатором), btn-group (компонентом), and btn-group-item (составной частью компонента) непросто, так как назначение классов не лежит на поверхности в их именах. Нет единой схемы.

В течение прошлого года я экспериментировал с системами именования, которые помогали бы мне быстрее понимать связи между узлами DOM-фрагмента в плане их оформления, а не пытаться собрать в кучу всю архитектуру сайта, «прыгая» туда-сюда между HTML-, CSS— и JS-файлами. Система сложилась преимущественно под влиянием подхода к именованию из методологии БЭМ, но я привел ее в более читаемую (на мой взгляд) форму.

t-template-name  t-template-name--modifier-name  t-template-name__sub-object  t-template-name__sub-object--modifier-name    component-name  component-name--modifier-name  component-name__sub-object  component-name__sub-object--modifier-name    is-state-type    js-action-name

Я рассматриваю некторые структуры как абстрактные шаблоны, а другие как более автономные компоненты (которые обычно строятся на основе шаблонов). Но такое разделение нужно не всегда.

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

Немного о «сыром» размере файла и HTTP-сжатии

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

Когда впервые появился Twitter Bootstrap, я переписал получившийся на выходе CSS, чтобы сравнить с тем, как я писал бы его вручную, и насколько различаются при этом размеры файла. После убирания пробелов вручную написанный CSS-файл был примерно на 10% меньше, чем вывод препроцессора. Однако после gzip-сжатия обоих файлов, результат работы препроцессора оказался примерно на 5% меньше, чем CSS «ручной работы».

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

В другом эксперименте я убрал все атрибуты class из 60-килобайтного HTML-файла, взятого с реального сайта (уже использовавшего множество многоразовых компонентов). Это уменьшило размер файла до 25 килобайт. Но после gzip-сжатия исходного и «вычищенного» файлов их размеры составляли 7,6 и 6 килобайт соответственно — всего 1,6 килобайта разницы. Фактическая значимость вольного использования классов редко стоит того, чтоб на ней зацикливаться.

Как я перестал беспокоиться…

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

Как только вы начнете писать нетривиальные сайты и веб-приложения, которые вам и другим приходится не только поддерживать, но и развивать, вы быстро поймете (о чем Николь Салливэн говорила годами) что, несмотря на все усилия, поддерживать ваш код будет всё труднее и труднее. И стоит потратить время на изучение работ тех людей, кто уже сталкивался с этой проблемой: блога Николь и проекта «Объектно-ориентированный CSS», масштабируемой модульной архитектуры CSS Джонатана Снука (SMACSS) и методологии «Блок, Элемент, Модификатор», разработанной командой «Яндекса»

Как только вы начнете создавать HTML и CSS, то для того, чтобы тратить меньше времени на написание и редактирование CSS, придется смириться с необходимостью тратить больше времени на изменение HTML-классов у элементов, если нужно изменить их стиль. И это оказыватся одинаково практично для разработчиков как клиентской, так и серверной части — каждый может легко переставлять готовые «кирпичики Lego»; оказывается, никто не может творить алхимию в CSS.

css-live.ru


You May Also Like

About the Author: admind

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

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

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