Какой семантический элемент отсутствует в html5

Семантические элементы HTML5

Семантика — это наука о значениях слов и фраз в языке. Таким образом, семантические элементы — это элементы со значением.

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

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

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

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

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

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

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

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

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

• <article>
• <aside>
• <details>
• <figcaption>
• <figure>
• <footer>
• <header>
• <main>
• <mark>
• <nav>
• <section>
• <summary>
• <time>

Элемент <section>

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

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

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

Элемент <article>

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

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

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

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

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

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

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

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

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

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

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

Элемент <header>

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

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

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

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

Элемент <footer>

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

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

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

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

Элемент <nav>

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

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

Элемент <aside>

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

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

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

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

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

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

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

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

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

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

Семантические элементы HTML5

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

Как использовать семантические теги HTML5?

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

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

Что такое семантические теги

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

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

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

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

Список новых тегов в HTML5

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

• <main> – используется для определения основного контента страницы. Он дает понять поисковому боту, что здесь содержится главный контент.
• <header> – «шапка» страницы или раздела, в которой обычно располагается навигация по сайту. Но так же этот тег можно использовать в других секция сайта, определяя в нем заголовок этой самой секции.
• <nav> – задает навигацию по сайту.
• <section> – обычно применяется для группировки разделов. Например, может применяться для блока новостей, контактной информации, глав текста, вкладок в диалоговом окне и др.
• <article> – может быть пост на форуме, статья в журнале или газете, заметка в блоге, сообщение пользователя или другая независимая контент-единица.
• <aside> – определяет блок сбоку от контента для размещения рубрик, ссылок на архив, меток и другой информации.
• <audio> – добавляет, воспроизводит и управляет настройками аудиозаписи на веб-странице.
• <video> – добавляет, воспроизводит и управляет настройками видеозаписи на веб-странице.
• <canvas> – создает область, в которой при помощи JavaScript можно рисовать разные объекты, выводить изображения, трансформировать их и менять свойства. При помощи тега <canvas> можно создавать рисунки, анимацию, игры и др.
• <footer> – задает «подвал» сайта или раздела, в нем может располагаться имя автора, дата документа, контактная информация или дополнительная навигация по сайту.
• <command> – устанавливает команду, срабатывающую при активации элемента (нажатием или сочетанием клавиш). Элемент может иметь вид кнопки, переключателя или флажка и должен быть вложен в элемент <menu>, в противном случае он не будет показан.
• <datalist> – создает список вариантов, которые можно выбирать при наборе в текстовом поле. Изначально этот список скрыт и становится доступным при получении полем фокуса или наборе текста.
• <details> – используется для хранения информации, которую можно скрыть или показать по требованию пользователя. По умолчанию содержимое тега не отображается, для изменения статуса применяется атрибут open.
• <embed> – используется для загрузки и отображения объектов (например, видеофайлов, флэш-роликов, некоторых звуковых файлов и т.д.), которые исходно браузер не понимает. Как правило, такие объекты требуют подключения к браузеру специального модуля, который называется плагин, или запуска вспомогательной программы.
• <hgroup> – используется для группирования заголовков веб-страницы или раздела. Внутри располагаются теги заголовков от <h1> до <h6>.
• <keygen> – отвечает за генерацию пары ключей (открытый и закрытый), которые используются для шифрования и расшифровки данных форм, а также для создания и проверки цифровой подписи. Открытый ключ отправляется на сервер вместе с данными формы, а закрытый сохраняется на локальном устройстве пользователя.
• <mark> – помечает текст как выделенный. Такой текст ничем не отличается от обычного, но его вид может быть изменен с помощью стилей. В браузере Chrome и Firefox фоновый цвет текста внутри <mark> выделяется желтым цветом.
• <meter> – используется для вывода значения в некотором известном диапазоне. Используется преимущественно для отображения числовых значений: например, количества результатов поиска, объема жидкости, давления и др.
• <output> – определяет область, в которую выводится информация, преимущественно с помощью скриптов.
• <progress> – используется для отображения прогресса завершенности задачи. Изменение значения происходит через JavaScript.
• <ruby> – используется вместе с <rt> и <rp>. Предназначен для добавления небольшой аннотации сверху или снизу от заданного текста. Такая форма записи преимущественно используется для идеографической письменности вроде китайского языка, но может применяться и для других языков, если требуется написать один текст над другим.
• <time> – помечает текст внутри тега <time> как дата, время или оба значения. Может указываться непосредственно внутри контейнера <time> либо задаваться через атрибут datetime.
• <wbr> — указывает браузеру место, где допускается делать перенос строки в тексте, если этого требует ширина родительского элемента.

Как использовать семантические теги

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

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

Давайте разберем простой пример:

Если внимательнее изучить структуру, вроде как понятно, что <div> c id header – это шапка сайта, <div> c id footer – это подвал сайта и т.д. Но к сожалению, такая структура будет понятна только разработчику и бесполезна для поисковых ботов. Для них это всего лишь кусок текста, который не несет никакого смысла.

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

Тут картина меняется сразу. Мы можем без труда и без каких-либо дополнительных атрибутов определить содержимое страницы. Теги <header>, <main> и <footer> четко разделили контент и не только повысили читаемость кода, но также расставили те самые “магазинные таблички”, которые будут направлять поисковых ботов по нужным разделам.

Ну или например блок статьи.

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

И напоследок давайте пройдемся по некоторым тегам, к которыми могут возникнуть вопросы.

Теги <article> и <section>

Возможно, у вас сразу возник вопрос: “В чем разница между этими тегами?”

<section> – смысловой или логический раздел документа;
<article> – самостоятельный и независимый раздел документа.

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

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

То есть блок <article> будет независимым и может использоваться в любом месте, но секции в нём уже не получится отделить и переиспользовать в другой части сайта, так как они связаны логически. И если удалить первую часть, то очевидно, что мы потеряем суть статьи.

Думаю суть уловили.

И если попробуем поменять теги местами,

то блоки <article> можно будет отделять и использовать в других местах, так как они независимы и не связаны друг с другом. Контент внутри них не зависит от предыдущего блока, и если его удалить, то суть не поменяется.

Тег <footer>

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

Тег <header>

То же самое можно сказать и про этот тег. Его можно располагать в начале страницы, над основным контентом, или в секции – размещать в нем, например, заголовок или навигацию.

Тег <nav>

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

Тег <aside>

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

Обычно располагается около тега <main>

Заключение

Я думаю, вы поняли, что использовать семантические теги не так уж и сложно. Главное – понять, где их применять и зачем 🙂

Если подвести итог, можно определить два основных плюса:

1. Теги избавляют структуру от лишнего мусора в виде дополнительных атрибутов. Код становится проще и понятнее.
2. Теги помогают быстрее обрабатывать код поисковым роботам, вследствие чего у вашего сайта больше шансов попасть на первые страницы Google, Yandex и т.д.

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

Узнать больше о новых элементах HTML5 можно тут:
w3schools – предоставляет простое и ясное описание многих html-элементов и того, как/где их следует использовать.
MDN – также предоставляет отличное описание всех элементов HTML + углубляется в каждый из них.

HTML5

If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.

If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element’s contents.

The target , download , rel , hreflang , and type attributes must be omitted if the href attribute is not present.

If a site uses a consistent navigation toolbar on every page, then the link that would normally link to the page itself could be marked up using an a element:

The href , target , download , and attributes affect what happens when users follow hyperlinks or download hyperlinks created using the a element. The rel , hreflang , and type attributes may be used to indicate to the user the likely nature of the target resource before the user follows the link.

The activation behavior of a elements that create hyperlinks is to run the following steps:

If either the a element has a download attribute and the algorithm is not allowed to show a popup, or the element’s target attribute is present and applying the rules for choosing a browsing context given a browsing context name, using the value of the target attribute as the browsing context name, would result in there not being a chosen browsing context, then run these substeps:

If the target of the click event is an img element with an ismap attribute specified, then server-side image map processing must be performed, as follows:

1. If the click event was a real pointing-device-triggered click event on the img element, then let x be the distance in CSS pixels from the left edge of the image’s left border, if it has one, or the left edge of the image otherwise, to the location of the click, and let y be the distance in CSS pixels from the top edge of the image’s top border, if it has one, or the top edge of the image otherwise, to the location of the click. Otherwise, let x and y be zero.
2. Let the be a U+003F QUESTION MARK character, the value of x expressed as a base-ten integer using ASCII digits, a «,» (U+002C) character, and the value of y expressed as a base-ten integer using ASCII digits.

The IDL attributes , , , , , and , must reflect the respective content attributes of the same name.

The IDL attribute must reflect the rel content attribute.

The IDL attribute, on getting, must return the same value as the textContent IDL attribute on the element, and on setting, must act as if the textContent IDL attribute on the element had been set to the new value.

The a element also supports the URLUtils interface. [URL]

When the element is created, and whenever the element’s href content attribute is set, changed, or removed, the user agent must invoke the element’s URLUtils interface’s set the input algorithm with the value of the href content attribute, if any, or the empty string otherwise, as the given value.

The element’s URLUtils interface’s get the base algorithm must simply return the element’s base URL.

When the element’s URLUtils interface invokes its update steps with a string value , the user agent must set the element’s href content attribute to the string value .

The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links). This example shows how this can be used to make an entire advertising block into a link:

4.5.2 The element

The em element represents stress emphasis of its contents.

The level of stress that a particular piece of content has is given by its number of ancestor em elements.

The placement of stress emphasis changes the meaning of the sentence. The element thus forms an integral part of the content. The precise way in which stress is used in this way depends on the language.

These examples show how changing the stress emphasis changes the meaning. First, a general statement of fact, with no stress:

By emphasizing the first word, the statement implies that the kind of animal under discussion is in question (maybe someone is asserting that dogs are cute):

Moving the stress to the verb, one highlights that the truth of the entire sentence is in question (maybe someone is saying cats are not cute):

By moving it to the adjective, the exact nature of the cats is reasserted (maybe someone suggested cats were mean animals):

Similarly, if someone asserted that cats were vegetables, someone correcting this might emphasize the last word:

By emphasizing the entire sentence, it becomes clear that the speaker is fighting hard to get the point across. This kind of stress emphasis also typically affects the punctuation, hence the exclamation mark here.

Anger mixed with emphasizing the cuteness could lead to markup such as:

The em element isn’t a generic «italics» element. Sometimes, text is intended to stand out from the rest of the paragraph, as if it was in a different mood or voice. For this, the i element is more appropriate.

The em element also isn’t intended to convey importance; for that purpose, the strong element is more appropriate.

4.5.3 The element

The strong element represents strong importance, seriousness, or urgency for its contents.

Importance: The strong element can be used in a heading, caption, or paragraph to distinguish the part that really matters from other parts of the that might be more detailed, more jovial, or merely boilerplate.

For example, the first word of the previous paragraph is marked up with strong to distinguish it from the more detailed text in the rest of the paragraph.

Seriousness: The strong element can be used to mark up a warning or caution notice.

Urgency: The strong element can be used to denote contents that the user needs to see sooner than other parts of the document.

The relative level of importance of a piece of content is given by its number of ancestor strong elements; each strong element increases the importance of its contents.

Changing the importance of a piece of text with the strong element does not change the meaning of the sentence.

Here, the word «chapter» and the actual chapter number are mere boilerplate, and the actual name of the chapter is marked up with strong :

In the following example, the name of the diagram in the caption is marked up with strong , to distinguish it from boilerplate text (before) and the description (after):

In this example, the heading is really «Flowers, Bees, and Honey», but the author has added a light-hearted addition to the heading. The strong element is thus used to mark up the first part to distinguish it from the latter part.

Here is an example of a warning notice in a game, with the various parts marked up according to how important they are:

In this example, the strong element is used to denote the part of the text that the user is intended to read first.

4.5.4 The element

The small element represents side comments such as small print.

Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements.

The small element does not «de-emphasize» or lower the importance of text emphasized by the em element or marked as important with the strong element. To mark text as not emphasized or important, simply do not mark it up with the em or strong elements respectively.

The small element should not be used for extended spans of text, such as multiple paragraphs, lists, or sections of text. It is only intended for short runs of text. The text of a page listing terms of use, for instance, would not be a suitable candidate for the small element: in such a case, the text is not a side comment, it is the main content of the page.

In this example, the small element is used to indicate that value-added tax is not included in a price of a hotel room:

In this second example, the small element is used for a side comment in an article.

This is distinct from a sidebar, which might be multiple paragraphs long and is removed from the main flow of text. In the following example, we see a sidebar from the same article. This sidebar also has small print, indicating the source of the information in the sidebar.

In this last example, the small element is marked as being important small print.

4.5.5 The element

The s element represents contents that are no longer accurate or no longer relevant.

The s element is not appropriate when indicating document edits; to mark a span of text as having been removed from a document, use the del element.

In this example a recommended retail price has been marked as no longer relevant as the product in question has a new sale price.

4.5.6 The element

The cite element represents a reference to a creative work. It must include the title of the work or the name of the author(person, people or organization) or an URL reference, which may be in an abbreviated form as per the conventions used for the addition of citation metadata.

Creative works include a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a web site, a web page, a blog post or comment, a forum post or comment, a tweet, a written or oral statement, etc.

Here is an example of the author of a quote referenced using the cite element:

This second example identifies the author of a tweet by referencing the authors name using the cite element:

In this example the cite element is used to reference the title of a work in a bibliography:

In this example the cite element is used to reference the title of a television show:

A very common use for the cite element is to identify the author of a comment in a blog post or forum, as in this example:

Another common use for the cite element is to reference the URL of a search result, as in this example:

A citation is not a quote (for which the q element is appropriate).

This is incorrect usage, because cite is not for quotes:

This is an example of the correct usage:

4.5.7 The element

The q element represents some phrasing content quoted from another source.

Quotation punctuation (such as quotation marks) that is quoting the contents of the element must not appear immediately before, after, or inside q elements; they will be inserted into the rendering by the user agent.

Content inside a q element must be quoted from another source, whose address, if it has one, may be cited in the attribute. The source may be fictional, as when quoting characters in a novel or screenplay.

If the cite attribute is present, it must be a valid URL potentially surrounded by spaces. To obtain the corresponding citation link, the value of the attribute must be resolved relative to the element. User agents may allow users to follow such citation links, but they are primarily intended for private use (e.g. by server-side scripts collecting statistics about a site’s use of quotations), not for readers.

The q element must not be used in place of quotation marks that do not represent quotes; for example, it is inappropriate to use the q element for marking up sarcastic statements.

The use of q elements to mark up quotations is entirely optional; using explicit quotation punctuation without q elements is just as correct.

Here is a simple example of the use of the q element:

Here is an example with both an explicit citation link in the q element, and an explicit citation outside:

In the following example, the quotation itself contains a quotation:

In the following example, quotation marks are used instead of the q element:

In the following example, there is no quote — the quotation marks are used to name a word. Use of the q element in this case would be inappropriate.

4.5.8 The element

The dfn element represents the defining instance of a term. The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element.

: If the dfn element has a attribute, then the exact value of that attribute is the term being defined. Otherwise, if it contains exactly one element child node and no child Text nodes, and that child element is an abbr element with a title attribute, then the exact value of that attribute is the term being defined. Otherwise, it is the exact textContent of the dfn element that gives the term being defined.

If the title attribute of the dfn element is present, then it must contain only the term being defined.

The title attribute of ancestor elements does not affect dfn elements.

An a element that links to a dfn element represents an instance of the term defined by the dfn element.

In the following fragment, the term «Garage Door Opener» is first defined in the first paragraph, then used in the second. In both cases, its abbreviation is what is actually displayed.

With the addition of an a element, the reference can be made explicit:

4.5.9 The element

The abbr element represents an abbreviation or acronym, optionally with its expansion. The attribute may be used to provide an expansion of the abbreviation. The attribute, if specified, must contain an expansion of the abbreviation, and nothing else.

The paragraph below contains an abbreviation marked up with the abbr element. This paragraph defines the term «Web Hypertext Application Technology Working Group».

An alternative way to write this would be:

This paragraph has two abbreviations. Notice how only one is defined; the other, with no expansion associated with it, does not use the abbr element.

This paragraph links an abbreviation to its definition.

This paragraph marks up an abbreviation without giving an expansion, possibly as a hook to apply styles for abbreviations (e.g. smallcaps).

If an abbreviation is pluralized, the expansion’s grammatical number (plural vs singular) must match the grammatical number of the contents of the element.

Here the plural is outside the element, so the expansion is in the singular:

Here the plural is inside the element, so the expansion is in the plural:

Abbreviations do not have to be marked up using this element. It is expected to be useful in the following cases:

• Abbreviations for which the author wants to give expansions, where using the abbr element with a title attribute is an alternative to including the expansion inline (e.g. in parentheses).
• Abbreviations that are likely to be unfamiliar to the document’s readers, for which authors are encouraged to either mark up the abbreviation using an abbr element with a title attribute or include the expansion inline in the text the first time the abbreviation is used.
• Abbreviations whose presence needs to be semantically annotated, e.g. so that they can be identified from a style sheet and given specific styles, for which the abbr element can be used without a title attribute.

Providing an expansion in a title attribute once will not necessarily cause other abbr elements in the same document with the same contents but without a title attribute to behave as if they had the same expansion. Every abbr element is independent.

4.5.10 The element

The data element represents its contents, along with a machine-readable form of those contents in the value attribute.

The attribute must be present. Its value must be a representation of the element’s contents in a machine-readable format.

When the value is date- or time-related, the more specific time element can be used instead.

The element can be used for several purposes.

When combined with microformats or microdata, the element serves to provide both a machine-readable value for the purposes of data processors, and a human-readable value for the purposes of rendering in a Web browser. In this case, the format to be used in the value attribute is determined by the microformats or microdata vocabulary in use.

The element can also, however, be used in conjunction with scripts in the page, for when a script has a literal value to store alongside a human-readable value. In such cases, the format to be used depends only on the needs of the script. (The data-* attributes can also be useful in such situations.)

The IDL attribute must reflect the content attribute of the same name.

4.5.11 The element

The time element represents its contents, along with a machine-readable form of those contents in the datetime attribute. The kind of content is limited to various kinds of dates, times, time-zone offsets, and durations, as described below.

The attribute may be present. If present, its value must be a representation of the element’s contents in a machine-readable format.

A time element that does not have a datetime content attribute must not have any element descendants.

The of a time element is the value of the element’s datetime content attribute, if it has one, or the element’s textContent , if it does not.

The datetime value of a time element must match one of the following syntaxes.

Times with dates but without a time zone offset are useful for specifying events that are observed at the same specific time in each time zone, throughout a day. For example, the 2020 new year is celebrated at 2020-01-01 00:00 in each time zone, not at the same precise moment across all time zones. For events that occur at the same time across all time zones, for example a videoconference meeting, a valid global date and time string is likely more useful.

For times without dates (or times referring to events that recur on multiple dates), specifying the geographic location that controls the time is usually more useful than specifying a time zone offset, because geographic locations change time zone offsets with daylight savings time. In some cases, geographic locations even change time zone, e.g. when the boundaries of those time zones are redrawn, as happened with Samoa at the end of 2011. There exists a time zone database that describes the boundaries of time zones and what rules apply within each such zone, known as the time zone database. [TZDATABASE]

Times with dates and a time zone offset are useful for specifying specific events, or recurring virtual events where the time is not anchored to a specific geographic location. For example, the precise time of an asteroid impact, or a particular meeting in a series of meetings held at 1400 UTC every day, regardless of whether any particular part of the world is observing daylight savings time or not. For events where the precise time varies by the local time zone offset of a specific geographic location, a valid floating date and time string combined with that geographic location is likely more useful.

A valid week string Four or more ASCII digits, at least one of which is not «0» (U+0030) A valid duration string

Many of the preceding valid syntaxes describe «floating» date and/or time values (they do not include a time-zone offset). Care is needed when converting floating time values to or from global («incremental») time values (e.g., JavaScript’s Date object). In many cases, an implicit time-of-day and time zone are used in the conversion and may result in unexpected changes to the value of the date itself. [TIMEZONES]

The must be obtained from the element’s datetime value by using the following algorithm:

The algorithms referenced above are intended to be designed such that for any arbitrary string s , only one of the algorithms returns a value. A more efficient approach might be to create a single algorithm that parses all these data types in one pass; developing such an algorithm is left as an exercise to the reader.

The IDL attribute must reflect the element’s datetime content attribute.

The time element can be used to encode dates, for example in microformats. The following shows a hypothetical way of encoding an event using a variant on hCalendar that uses the time element:

Here, a fictional microdata vocabulary based on the Atom vocabulary is used with the time element to mark up a blog post’s publication date.

In this example, another article’s publication date is marked up using time , this time using the schema.org microdata vocabulary:

In the following snippet, the time element is used to encode a date in the ISO8601 format, for later processing by a script:

In this second snippet, the value includes a time:

A script loaded by the page (and thus privy to the page’s internal convention of marking up dates and times using the time element) could scan through the page and look at all the time elements therein to create an index of dates and times.

For example, this element conveys the string «Tuesday» with the additional semantic that the 12th of November 2011 is the meaning that corresponds to «Tuesday»:

In this example, a specific time in the Pacific Standard Time timezone is specified:

4.5.12 The element

The code element represents a fragment of computer code. This could be an XML element name, a file name, a computer program, or any other string that a computer would recognize.

There is no formal way to indicate the language of computer code being marked up. Authors who wish to mark code elements with the language used, e.g. so that syntax highlighting scripts can use the right rules, can use the class attribute, e.g. by adding a class prefixed with » language- » to the element.

The following example shows how the element can be used in a paragraph to mark up element names and computer code, including punctuation.

The following example shows how a block of code could be marked up using the pre and code elements.

A class is used in that example to indicate the language used.

See the pre element for more details.

4.5.13 The element

The var element represents a variable. This could be an actual variable in a mathematical expression or programming context, an identifier representing a constant, a symbol identifying a physical quantity, a function parameter, or just be a term used as a placeholder in prose.

In the paragraph below, the letter «n» is being used as a variable in prose:

For mathematics, in particular for anything beyond the simplest of expressions, MathML is more appropriate. However, the var element can still be used to refer to specific variables that are then mentioned in MathML expressions.

In this example, an equation is shown, with a legend that references the variables in the equation. The expression itself is marked up with MathML, but the variables are mentioned in the figure’s legend using var .

Here, the equation describing mass-energy equivalence is used in a sentence, and the var element is used to mark the variables and constants in that equation:

4.5.14 The element

The samp element represents (sample) output from a program or computing system.

See the pre and kbd elements for more details.

This example shows the samp element being used inline:

This second example shows a block of sample output. Nested samp and kbd elements allow for the styling of specific elements of the sample output using a style sheet. There’s also a few parts of the samp that are annotated with even more detailed markup, to enable very precise styling. To achieve this, span elements are used.

4.5.15 The element

The kbd element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).

When the kbd element is nested inside a samp element, it represents the input as it was echoed by the system.

When the kbd element contains a samp element, it represents input based on system output, for example invoking a menu item.

When the kbd element is nested inside another kbd element, it represents an actual key or other single unit of input as appropriate for the input mechanism.

Here the kbd element is used to indicate keys to press:

In this second example, the user is told to pick a particular menu item. The outer kbd element marks up a block of input, with the inner kbd elements representing each individual step of the input, and the samp elements inside them indicating that the steps are input based on something being displayed by the system, in this case menu labels:

Such precision isn’t necessary; the following is equally fine:

4.5.16 The and elements

The sup element represents a superscript and the sub element represents a subscript.

These elements must be used only to mark up typographical conventions with specific meanings, not for typographical presentation for presentation’s sake. For example, it would be inappropriate for the sub and sup elements to be used in the name of the LaTeX document preparation system. In general, authors should use these elements only if the absence of those elements would change the meaning of the content.

In certain languages, superscripts are part of the typographical conventions for some abbreviations.

The sub element can be used inside a var element, for variables that have subscripts.

Here, the sub element is used to represent the subscript that identifies the variable in a family of variables:

Mathematical expressions often use subscripts and superscripts. Authors are encouraged to use MathML for marking up mathematics, but authors may opt to use sub and sup if detailed mathematical markup is not desired. [MATHML]

4.5.17 The element

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.

Terms in languages different from the main text should be annotated with lang attributes (or, in XML, lang attributes in the XML namespace ).

The examples below show uses of the i element:

In the following example, a dream sequence is marked up using i elements.

Authors can use the class attribute on the i element to identify why the element is being used, so that if the style of a particular use (e.g. dream sequences as opposed to taxonomic terms) is to be changed at a later date, the author doesn’t have to go through the entire document (or series of related documents) annotating each use.

Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term.

Style sheets can be used to format i elements, just like any other element can be restyled. Thus, it is not the case that content in i elements will necessarily be italicized.

4.5.18 The element

The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede.

The following example shows a use of the b element to highlight key words without marking them up as important:

In the following example, objects in a text adventure are highlighted as being special by use of the b element.

Another case where the b element is appropriate is in marking up the lede (or lead) sentence or paragraph. The following example shows how a BBC article about kittens adopting a rabbit as their own could be marked up:

As with the i element, authors can use the class attribute on the b element to identify why the element is being used, so that if the style of a particular use is to be changed at a later date, the author doesn’t have to go through annotating each use.

The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

The following would be incorrect usage:

In the previous example, the correct element to use would have been strong , not b .

Style sheets can be used to format b elements, just like any other element can be restyled. Thus, it is not the case that content in b elements will necessarily be boldened.

4.5.19 The element

The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.

In most cases, another element is likely to be more appropriate: for marking stress emphasis, the em element should be used; for marking key words or phrases either the b element or the mark element should be used, depending on the context; for marking book titles, the cite element should be used ; for labeling text with explicit textual annotations, the ruby element should be used; for labeling ship names in Western texts, the i element should be used.

The default rendering of the u element in visual presentations clashes with the conventional rendering of hyperlinks (underlining). Authors are encouraged to avoid using the u element where it could be confused for a hyperlink.

4.5.20 The element

The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to bring the reader’s attention to a part of the text that might not have been considered important by the original author when the block was originally written, but which is now under previously unexpected scrutiny. When used in the main prose of a document, it indicates a part of the document that has been highlighted due to its likely relevance to the user’s current activity.

This example shows how the mark element can be used to bring attention to a particular part of a quotation:

(If the goal was to mark the element as misspelt, however, the u element, possibly with a class, would be more appropriate.)

Another example of the mark element is highlighting parts of a document that are matching some search string. If someone looked at a document, and the server knew that the user was searching for the word «kitten», then the server might return the document with one paragraph modified as follows:

In the following snippet, a paragraph of text refers to a specific part of a code fragment.

This is separate from syntax highlighting, for which span is more appropriate. Combining both, one would get:

This is another example showing the use of mark to highlight a part of quoted text that was originally not emphasized. In this example, common typographic conventions have led the author to explicitly style mark elements in quotes to render in italics.

Note, incidentally, the distinction between the em element in this example, which is part of the original text being quoted, and the mark element, which is highlighting a part for comment.

The following example shows the difference between denoting the importance of a span of text ( strong ) as opposed to denoting the relevance of a span of text ( mark ). It is an extract from a textbook, where the extract has had the parts relevant to the exam highlighted. The safety warnings, important though they may be, are apparently not relevant to the exam.

4.5.21 The element

The ruby element allows one or more spans of phrasing content to be marked with ruby annotations. Ruby annotations are short runs of text presented alongside base text, primarily used in East Asian typography as a guide for pronunciation or to include other annotations. In Japanese, this form of typography is also known as furigana. Ruby text can appear on either side, and sometimes both sides, of the base text, and it is possible to control its position using CSS. A more complete introduction to ruby can be found in the Use Cases & Exploratory Approaches for Ruby Markup document as well as in CSS Ruby Module Level 1 . [RUBY-UC] [CSSRUBY]

The content model of ruby elements consists of one or more of the following sequences:

1. One or more phrasing content nodes or rb elements.
2. One or more rt or rtc elements, each of which either immediately preceded or followed by an rp elements.

The ruby , rb , rtc , and rt elements can be used for a variety of kinds of annotations, including in particular (though by no means limited to) those described below. For more details on Japanese Ruby in particular, and how to render Ruby for Japanese, see Requirements for Japanese Text Layout . [JLREQ] The rp element can be used as fallback content when ruby rendering is not supported.

Mono-ruby for individual base characters

Annotations (the ruby text) are associated individually with each ideographic character (the base text). In Japanese this is typically hiragana or katakana characters used to provide readings of kanji characters.

When no rb element is used, the base is implied, as above. But you can also make it explicit. This can be useful notably for styling, or when consecutive bases are to be treated as a group, as in the jukugo ruby example further down.

In the following example, notice how each annotation corresponds to a single base character.

Ruby text interspersed in regular text provides structure akin to the following image:

This example can also be written as follows, using one ruby element with two segments of base text and two annotations (one for each) rather than two back-to-back ruby elements each with one base text segment and annotation (as in the markup above):

Group ruby is often used where phonetic annotations don’t map to discreet base characters, or for semantic glosses that span the whole base text. For example, the word «today» is written with the characters 今日, literally «this day». But it’s pronounced きょう (kyou), which can’t be broken down into a «this» part and a «day» part. In typical rendering, you can’t split text that is annotated with group ruby; it has to wrap as a single unit onto the next line. When a ruby text annotation maps to a base that is comprised of more than one character, then that base is grouped.

The following group ruby:

Can be marked up as follows:

Jukugo refers to a Japanese compound noun, i.e. a word made up of more than one kanji character. Jukugo ruby is a term that is used not to describe ruby annotations over jukugo text, but rather to describe ruby with a behaviour slightly different from mono or group ruby. Jukugo ruby is similar to mono ruby, in that there is a strong association between ruby text and individual base characters, but the ruby text is typically rendered as grouped together over multiple ideographs when they are on the same line.

The distinction is captured in this example:

Which can be marked up as follows:

In this example, each rt element is paired with its respective rb element, the difference with an interleaved rb / rt approach being that the sequences of both base text and ruby annotations are implicitly placed in common containers so that the grouping information is captured.

For more details on Jukugo Ruby rendering, see Appendix F in the Requirements for Japanese Text Layout and Use Case C: Jukugo ruby in the Use Cases & Exploratory Approaches for Ruby Markup . [JLREQ] [RUBY-UC]

In some contexts, for instance when the font size or line height are too small for ruby to be readable, it is desirable to inline the ruby annotation such that it appears in parentheses after the text it annotates. This also provides a convenient fallback strategy for user agents that do not support rendering ruby annotations.

Inlining takes grouping into account. For example, Tokyo is written with two kanji characters, 東, which is pronounced とう, and 京, which is pronounced きょう. Each base character should be annotated individually, but the fallback should be 東京(とうきょう) not 東(とう)京(きょう). This can be marked up as follows:

Note that the above markup will enable the usage of parentheses when inlining for browsers that support ruby layout, but for those that don’t it will fail to provide parenthetical fallback. This is where the rp element is useful. It can be inserted into the above example to provide the appropriate fallback when ruby layout is not supported:

Sometimes, ruby can be used to annotate a base twice.

In the following example, the Chinese word for San Francisco (旧金山, i.e. “old gold mountain”) is annotated both using pinyin to give the pronunciation, and with the original English.

Which is marked up as follows:

In this example, a single base run of three base characters is annotated with three pinyin ruby text segments in a first (implicit) container, and an rtc element is introduced in order to provide a second single ruby text annotation being the city’s English name.

We can also revisit our jukugo example above with 上手 («skill») to show how it can be annotation in both kana and romaji phonetics while at the same time maintaining the pairing to bases and annotation grouping information.

Which is marked up as follows:

Text that is a direct child of the rtc element implicitly produces a ruby text segment as if it were contained in an rt element. In this contrived example, this is shown with some symbols that are given names in English and French with annotations intended to appear on either side of the base symbol.

Similarly, text directly inside a ruby element implicitly produces a ruby base as if it were contained in an rb element, and rt children of ruby are implicitly contained in an rtc container. In effect, the above example is equivalent (in meaning, though not in the DOM it produces) to the following:

Within a ruby element, content is parcelled into a series of ruby segments. Each is described by:

• Zero or more , each of which is a DOM range that may contain phrasing content or an rb element.
• A base range, that is a DOM range including all the bases. This is the .
• Zero or more ruby text containers which may correspond to explicit rtc elements, or to sequences of rt elements implicitly recognised as contained in an anonymous ruby text container.

Each is described by zero or more each of which is a DOM range that may contain phrasing content or an rt element, and an annotations range that is a range including all the annotations for that container. A ruby text container is also known (primarily in a CSS context) as a .

Furthermore, a ruby element contains . Ignored ruby content does not form part of the document’s semantics. It consists of some inter-element whitespace and rp elements, the latter of which are used for legacy user agents that do not support ruby at all.

The process of associates ruby annotations with ruby bases. Within each ruby segment, each ruby base in the ruby base container is paired with one ruby text annotation from the ruby text container, in order. If there are not enough ruby text annotations in a ruby annotation container, the last one is associated with any excess ruby bases. (If there are not any in the ruby annotation container, an anonymous empty one is assumed to exist.) If there are not enough ruby bases, any remaining ruby text annotations are assumed to be associated with empty, anonymous bases inserted at the end of the ruby base container.

Informally, the segmentation and categorisation algorithm below performs a simple set of tasks. First it processes adjacent rb elements, text nodes, and non-ruby elements into a list of bases. Then it processes any number of rtc elements or sequences of rt elements that are considered to automatically map to an anonymous ruby text container. Put together these data items form a ruby segment as detailed in the data model above. It will continue to produce such segments until it reaches the end of the content of a given ruby element. The complexity of the algorithm below compared to this informal description stems from the need to support an author-friendly syntax and being mindful of inter-element white space.

At any particular time, the element is the result that would be obtained from running the following algorithm:

1. Let root be the ruby element for which the algorithm is being run.
2. Let index be 0.
3. Let ruby segments be an empty list.
4. Let current bases be an empty list of DOM ranges.
5. Let current bases range be null.
6. Let current bases range start be null.
7. Let current annotations be an empty list of DOM ranges.
8. Let current annotations range be null.
9. Let current annotations range start be null.
10. Let current annotation containers be an empty list.
11. Let current automatic base nodes be an empty list of DOM Nodes.
12. Let current automatic base range start be null.
13. Process a ruby child: If index is equal to or greater than the number of child nodes in root , then run the steps to commit a ruby segment, return ruby segments , and abort these steps.
14. Let current child be the index th node in root .
15. If current child is not a Text node and is not an Element node, then increment index by one and jump to the step labelled process a ruby child.
16. If current child is an rp element, then increment index by one and jump to the step labelled process a ruby child. (Note that this has the effect of including this element in any range that we are currently processing. This is done intentionally so that misplaced rp can be processed correctly; semantically they are ignored all the same.)
17. If current child is an rt element, then run these substeps:
    1. Run the steps to commit an automatic base.
    2. Run the steps to commit the base range.
    3. If current annotations is empty, set current annotations range start to the value of index .
    4. Create a new DOM range whose start is the boundary point ( root , index ) and whose end is the boundary point ( root , index plus one), and append it at the end of current annotations .
    5. Increment index by one and jump to the step labelled process a ruby child.
    1. Run the steps to commit an automatic base.
    2. Run the steps to commit the base range.
    3. Run the steps to commit current annotations.
    4. Create a new ruby annotation container. It is described by the list of annotations returned by running the steps to process an rtc element and a DOM range whose start is the boundary point ( root , index ) and whose end is the boundary point ( root , index plus one). Append this new ruby annotation container at the end of current annotation containers .
    5. Increment index by one and jump to the step labelled process a ruby child.
    1. If current annotations is not empty, increment index by one and jump to the step labelled process a ruby child.
    2. Run the following substeps:
       1. Let lookahead index be set to the value of index .
       2. Peek ahead: Increment lookahead index by one.
       3. If lookahead index is equal to or greater than the number of child nodes in root , then abort these substeps.
       4. Let peek child be the lookahead index th node in root .
       5. If peek child is a Text node and is inter-element whitespace, then jump to the step labelled peek ahead.
       6. If peek child is an rt element, an rtc element, or an rp element, then set index to the value of lookahead index and jump to the step labelled process a ruby child.
       1. Run the steps to commit an automatic base.
       2. If current bases is empty, then set current bases range start to the value of index .
       3. Create a new DOM range whose start is the boundary point ( root , index ) and whose end is the boundary point ( root , index plus one), and append it at the end of current bases .
       4. Increment index by one and jump to the step labelled process a ruby child.

       When the steps above say to , it means to run the following steps at that point in the algorithm:

       1. Run the steps to commit an automatic base.
       2. If current bases , current annotations , and current annotation containers are all empty, abort these steps.
       3. Run the steps to commit the base range.
       4. Run the steps to commit current annotations.
       5. Create a new ruby segment. It is described by a list of bases set to current bases , a base DOM range set to current bases range , and a list of ruby annotation containers that are the current annotation containers list. Append this new ruby segment at the end of ruby segments .
       6. Let current bases be an empty list.
       7. Let current bases range be null.
       8. Let current bases range start be null.
       9. Let current annotation containers be an empty list.

       When the steps above say to , it means to run the following steps at that point in the algorithm:

       1. If current bases is empty, abort these steps.
       2. If current bases range is not null, abort these steps.
       3. Let current bases range be a DOM range whose start is the boundary point ( root , current bases range start ) and whose end is the boundary point ( root , index ).

       When the steps above say to , it means to run the following steps at that point in the algorithm:

       1. If current annotations is not empty and current annotations range is null let current annotations range be a DOM range whose start is the boundary point ( root , current annotations range start ) and whose end is the boundary point ( root , index ).
       2. If current annotations is not empty, create a new ruby annotation container. It is described by an annotations list set to current annotations and a range set to current annotations range . Append this new ruby annotation container at the end of current annotation containers .
       3. Let current annotations be an empty list of DOM ranges.
       4. Let current annotations range be null.
       5. Let current annotations range start be null.

       When the steps above say to , it means to run the following steps at that point in the algorithm:

       1. If current automatic base nodes is empty, abort these steps.
       2. If current automatic base nodes contains nodes that are not Text nodes, or Text nodes that are not inter-element whitespace, then run these substeps:
          1. It current bases is empty, set current bases range start to the value of current automatic base range start .
          2. Create a new DOM range whose start is the boundary point ( root , current automatic base range start ) and whose end is the boundary point ( root , index ), and append it at the end of current bases .

          4.5.22 The element

          An rb element’s end tag may be omitted if the rb element is immediately followed by an rb , rt , rtc or rp element, or if there is no more content in the parent element. Allowed ARIA role attribute values: Any role value. Allowed ARIA state and property attributes: Global aria-* attributes Any aria-* attributes applicable to the allowed roles. DOM interface: Uses HTMLElement .

          The rb element marks the base text component of a ruby annotation. When it is the child of a ruby element, it doesn’t represent anything itself, but its parent ruby element uses it as part of determining what it represents.

          An rb element that is not a child of a ruby element represents the same thing as its children.

          4.5.23 The element

          An rt element’s end tag may be omitted if the rt element is immediately followed by an rb , rt , rtc or rp element, or if there is no more content in the parent element. Allowed ARIA role attribute values: Any role value. Allowed ARIA state and property attributes: Global aria-* attributes Any aria-* attributes applicable to the allowed roles. DOM interface: Uses HTMLElement .

          The rt element marks the ruby text component of a ruby annotation. When it is the child of a ruby element or of an rtc element that is itself the child of a ruby element, it doesn’t represent anything itself, but its ancestor ruby element uses it as part of determining what it represents.

          An rt element that is not a child of a ruby element or of an rtc element that is itself the child of a ruby element represents the same thing as its children.

          4.5.24 The element

          An rtc element’s end tag may be omitted if the rtc element is immediately followed by an rb , rtc or rp element, or if there is no more content in the parent element. Allowed ARIA role attribute values: Any role value. Allowed ARIA state and property attributes: Global aria-* attributes Any aria-* attributes applicable to the allowed roles. DOM interface: Uses HTMLElement .

          The rtc element marks a ruby text container for ruby text components in a ruby annotation. When it is the child of a ruby element it doesn’t represent anything itself, but its parent ruby element uses it as part of determining what it represents.

          An rtc element that is not a child of a ruby element represents the same thing as its children.

          When an rtc element is processed as part of the segmentation and categorisation of content for a ruby element, the following algorithm defines how to :

          1. Let root be the rtc element for which the algorithm is being run.
          2. Let index be 0.
          3. Let annotations be an empty list of DOM ranges.
          4. Let current automatic annotation nodes be an empty list of DOM nodes.
          5. Let current automatic annotation range start be null.
          6. Process an rtc child: If index is equal to or greater than the number of child nodes in root , then run the steps to commit an automatic annotation, return annotations , and abort these steps.
          7. Let current child be the index th node in root .
          8. If current child is an rt element, then run these substeps:
             1. Run the steps to commit an automatic annotation.
             2. Create a new DOM range whose start is the boundary point ( root , index ) and whose end is the boundary point ( root , index plus one), and append it at the end of annotations .
             3. Increment index by one and jump to the step labelled process an rtc child.

             When the steps above say to , it means to run the following steps at that point in the algorithm:

             1. If current automatic annotation nodes is empty, abort these steps.
             2. If current automatic annotation nodes contains nodes that are not Text nodes, or Text nodes that are not inter-element whitespace, then create a new DOM range whose start is the boundary point ( root , current automatic annotation range start ) and whose end is the boundary point ( root , index ), and append it at the end of annotations .
             3. Let current automatic annotation nodes be an empty list of DOM nodes.
             4. Let current automatic annotation range start be null.

             4.5.25 The element

             An rp element’s end tag may be omitted if the rp element is immediately followed by an rb , rt , rtc or rp element, or if there is no more content in the parent element. Allowed ARIA role attribute values: Any role value. Allowed ARIA state and property attributes: Global aria-* attributes Any aria-* attributes applicable to the allowed roles. DOM interface: Uses HTMLElement .

             The rp element is used to provide fallback text to be shown by user agents that don’t support ruby annotations. One widespread convention is to provide parentheses around the ruby text component of a ruby annotation.

             The contents of the rp elements are typically not displayed by user agents which do support ruby annotations

             An rp element that is a child of a ruby element represents nothing. An rp element whose parent element is not a ruby element represents its children.

             The example shown previously, in which each ideograph in the text 漢字 is annotated with its phonetic reading, could be expanded to use rp so that in legacy user agents the readings are in parentheses (please note that white space has been introduced into this example in order to make it more readable):

             In conforming user agents the rendering would be as above, but in user agents that do not support ruby, the rendering would be:

             When there are multiple annotations for a segment, rp elements can also be placed between the annotations. Here is another copy of an earlier contrived example showing some symbols with names given in English and French using double-sided annotations, but this time with rp elements as well:

             This would make the example render as follows in non-ruby-capable user agents:

             4.5.26 The element

             The bdi element represents a span of text that is to be isolated from its surroundings for the purposes of bidirectional text formatting. [BIDI]

             The dir global attribute defaults to auto on this element (it never inherits from the parent element like with other elements).

             This element is especially useful when embedding user-generated content with an unknown directionality.

             In this example, usernames are shown along with the number of posts that the user has submitted. If the bdi element were not used, the username of the Arabic user would end up confusing the text (the bidirectional algorithm would put the colon and the number «3» next to the word «User» rather than next to the word «posts»).

             4.5.27 The element

             The bdo element represents explicit text directionality formatting control for its children. It allows authors to override the Unicode bidirectional algorithm by explicitly specifying a direction override. [BIDI]

             Authors must specify the dir attribute on this element, with the value ltr to specify a left-to-right override and with the value rtl to specify a right-to-left override. The auto value must not be specified.

             4.5.28 The element

             The span element doesn’t mean anything on its own, but can be useful when used together with the global attributes, e.g. class , lang , or dir . It represents its children.

             In this example, a code fragment is marked up using span elements and class attributes so that its keywords and identifiers can be color-coded from CSS:

             4.5.29 The element

             The br element represents a line break.

             While line breaks are usually represented in visual media by physically moving subsequent text to a new line, a style sheet or user agent would be equally justified in causing line breaks to be rendered in a different manner, for instance as green dots, or as extra spacing.

             br elements must be used only for line breaks that are actually part of the content, as in poems or addresses.

             The following example is correct usage of the br element:

             br elements must not be used for separating thematic groups in a paragraph.

             The following examples are non-conforming, as they abuse the br element:

             Here are alternatives to the above, which are correct:

             If a paragraph consists of nothing but a single br element, it represents a placeholder blank line (e.g. as in a template). Such blank lines must not be used for presentation purposes.

             Any content inside br elements must not be considered part of the surrounding text.

             4.5.30 The element

             The wbr element represents a line break opportunity.

             In the following example, someone is quoted as saying something which, for effect, is written as one long word. However, to ensure that the text can be wrapped in a readable fashion, the individual words in the quote are separated using a wbr element.

             Here, especially long lines of code in a program listing have suggested wrapping points given using wbr elements.

             Any content inside wbr elements must not be considered part of the surrounding text.

             Какой семантический элемент отсутствует в html5: Семантические элементы HTML5

             Семантика — это наука о значениях слов и фраз в языке. Таким образом, семантические элементы — это элементы со значением.

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

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

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

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

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

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

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

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

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

             • <article>
             • <aside>
             • <details>
             • <figcaption>
             • <figure>
             • <footer>
             • <header>
             • <main>
             • <mark>
             • <nav>
             • <section>
             • <summary>
             • <time>

             Элемент <section>

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

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

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

             Элемент <article>

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

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

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

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

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

             HTML5 Семантика

             Семантика — это изучение значений слов и фраз на языке.

             Семантические элементы = элементы со смыслом.

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

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

             Примеры несемантических элементов: <div> и <span> — Ничего не говорит о его содержании.

             Примеры семантических элементов:

             Поддержка браузеров

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

             Кроме того, вы можете «выучить» как обращаються старые браузеры с «неизвестными элементами».

             Читайте об этом в Поддержка браузеров HTML5.

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

             Многие веб-сайты содержат код HTML как: <div> <div> <div>
             для обозначения навигации, верхнего и нижнего колонтитулов.

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

             • <article>
             • <aside>
             • <details>
             • <figcaption>
             • <figure>
             • <footer>
             • <header>
             • <main>
             • <mark>
             • <nav>
             • <section>
             • <summary>
             • <time>

             Элемент <section> HTML5

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

             Согласно документации HTML5 W3C: «section — это тематическая группа контента, обычно с заголовком.»

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

             Элемент <article> HTML5

             Элемент <article> задает независимое, автономное содержимое.

             Статья должна иметь смысл сама по себе и ее можно читать независимо от остальной части веб-сайта.

             Примеры того, где можно использовать элемент <article> :

             • Сообщения форумов
             • Блог
             • Газетная статья

             Пример

             <article>
             <h2>Что делает WWF?</h2>
             <p>Миссия WWF — остановить деградацию естественной среды нашей планеты,
             построить будущее, в котором люди заживут в гармонии с природой.</p>
             </article>

             Вложить <article> в <section> или наоборот?

             Элемент <article> задает независимое, автономное содержимое.

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

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

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

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

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

             Элемент <header> HTML5

             Элемент <header> задает заголовок документа или раздела.

             Элемент <header> должен использоваться в качестве контейнера для вводного содержимого.

             Можно использовать несколько элементов <header> в одном документе.

             В следующем примере определяется заголовок статьи:

             Пример

             <article>
             <header>
             <h2>Что делает WWF?</h2>
             <p>Миссия WWF:</p>
             </header>
             <p>Миссия WWF — остановить деградацию естественной среды нашей планеты ,
             постройть будущее, в котором люди будут жить в гармонии с природой.</p>
             </article>

             Элемент <footer> HTML5

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

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

             Можно использовать несколько элементов <footer> в одном документе.

             Пример

             Элемент <nav> HTML5

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

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

             Пример

             Элемент <aside> HTML5

             Элемент <aside> определяет некоторое содержимое aside из контента, в который он помещен (например, боковая панель).

             Содержимое <aside> должно быть связано с окружающим контентом.

             Пример

             <aside>
             <h5>Центр Epcot</h5>
             <p>Epcot — это тематический парк в Диснейуорлде, штат Флорида.</p>
             </aside>

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

             Цель подписи к рисунку — добавить визуальное объяснение к изображению.

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

             Пример

             <figure>
             <img src=»pic_mountain.jpg» alt=»Пульпит Рок»>
             <figcaption>Рис. 1. — Прекестулен, Норвегия.</figcaption>
             </figure>

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

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

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

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

             Новые элементы HTML5 ( <header> <footer> <nav> <section> <article> ), станет легче выполнить.

             Согласно W3C, семантический веб: «Позволяет совместно и повторно использовать данные между приложениями, предприятиями и сообществами.»

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

             Ниже приведен алфавитный список новых семантических элементов в HTML5.

             Ссылка к нашему полному Справочнику HTML5.

             Семантика – это изучение значений слов и фраз на языке.

             Семантические элементы = элементы с смыслом.

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

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

             Примеры не семантических элементов: <div> и <span> — ничего не говорит о его содержимом.

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

             Поддержка браузера

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

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

             Прочитайте об этом в поддержке браузера HTML5.

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

             Многие веб-узлы содержат HTML-код, например: < div > < div > < div колонтитул» >
             для обозначения навигации, верхнего и нижнего колонтитулов.

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

             • <article>
             • <aside>
             • <details>
             • <figcaption>
             • <figure>
             • <footer>
             • <header>
             • <main>
             • <mark>
             • <nav>
             • <section>
             • <summary>
             • <time>

             HTML5 <section> элемент

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

             Согласно документации в3к’с HTML5: «раздел представляет собой тематическую группировку контента, обычно с заголовком».

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

             Пример

             Семантика в HTML 5 / Хабр

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

             Так же существуют изменения в структуре, синтаксисе и семантике HTML, некоторые из них описал Lachlan Hunt в статье «Обзор HTML 5» (перевод на хабре).

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

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

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

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

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

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

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

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

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

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

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

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

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

             * This source code was highlighted with Source Code Highlighter.

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

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

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

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

             Добавляя эти элементы, мы рассматриваем необходимость повышения потенциала семантики 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», но название не важно. Мы можем использовать его так:

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

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

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

             Расширяемость через атрибуты

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

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

             Например XHTML атрибут role работает следующим образом:

             <ul role=»navigation sitemap»>
             <li href=»downloads»>Downloads</li>
             <li href=»docs»>Documentation</li>
             <li href=»news»>News</li>
             </ul>

             * This source code was highlighted with Source Code Highlighter.

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

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

             Вот еще один пример. Все более очевидно, что в HTML не хватает представления машино-читаемого значения понятным для человека, например даты. Это лежит в основе проблемы BBC с микроформатом hCalendar, о ней мы говорили ранее. Хотя May Day next year действительно не имеет смысла, зато по аналогии May Day next year будет.

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

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

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

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

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

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

             Семантика в HTML5 | htmlbook.ru

             Иллюстрации: Кевин Корнелл

             Перевод: Влад Мержевич

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

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

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

             Есть также изменения в структуре, синтаксисе и семантике HTML, которые частично описал Лаклан Хант в статье Предварительный обзор HTML 5.

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

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

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

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

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

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

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

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

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

             Итак, как HTML5 решет этот вопрос? HTML5 вводит ряд новых элементов, некоторые из них я назвал «структурными» — <section>, <nav>, <aside>, <header> и <footer>. Элемент <dialog> по типу содержимого похож на <blockquote>. Есть также ряд элементов данных, таких как <meter>, который «представляет скалярное измерение в известном диапазоне или дробное значение, например, используемый объем диска» и элемент <time>, который указывает дату и/или время.

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

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

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

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

             Похоже, отличное начало. Но когда мы пытаемся установить, к примеру, такой стиль для элемента <section>:

             …большинство упомянутых браузеров изменило стиль элемента, но IE8 (а также IE6–7) нет.

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

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

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

             Совместимость с будущими версиями

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

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

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

             Некоторые соображения по поводу решения

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

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

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

             Посмотрим, как наши браузеры справятся с ним. И конечно все браузеры должны изменить его стиль через CSS.

             Но как это сделать?

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

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

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

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

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

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

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

             Вот еще один пример. Очевидно, что в HTML не хватает способа прикрепить версии для машинного чтения к версии для чтения человеком, например, дате. Это лежит в основе проблемы Би-би-си с микроформатом hCalendar, о которой мы говорили ранее. Хотя <span role=»2009-05-01″>Первого мая следующего года</span> действительно не несёт смысла, нечто вроде строки <span equivalent=»2009-05-01″>Первого мая следующего года</span> появится.

             Опять же, будем ли мы использовать определенный термин «equivalent» или какой-либо другой термин для этого семантического атрибута не важно. Главное отметить, что это не так просто, как использование одного атрибута class или role на все случаи. Для правильного расширяемого решения, которое обеспечивает обратную совместимость и достаточную гибкость, решения в этом направлении заслуживают изучения. Я назвал этот раздел «Некоторые соображения по поводу решения», поскольку нужно сделать значительный объем работы, чтобы действительно добиться приемлемого решения. Открытые вопросы включают следующее.

             • Сколько разных семантических атрибутов должно быть? Расширяются ли категории и если да, то как?
             • Как определяются словари?
             • Мы просто изобретаем желаемые термины подобно тому, как используется атрибут class или возможные значения должны определяться стандартной спецификацией? Или должен быть механизм для внедрения (и надеюсь обмена) словарями с помощью какого-то профиля?
             • Если возникает конфликт между двумя словарями вроде двух одинаковых терминов в разных словарях, как он разрешается?
             • Требуется ли пространство имён или другой подобный механизм?

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

             HTML5 | Семантические элементы

             Веб-программирование — HTML5 — Семантические элементы

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

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

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

             Эта ситуация заставила разработчиков задуматься, нельзя ли заменить элемент <div> чем-либо лучшим? Чем-то, что работало бы подобно <div>, но было бы более осмысленным. Чем-то, что помогло бы отделить боковые панели от заголовков, а рекламные панели от меню. Стандарт HTML5 позволяет сделать эту мечту реальностью, предоставляя набор новых элементов для структурирования страниц.

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

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

             В браузере эта разметка отображается как обычный текст «Регистрация начнется 2012-11-25».

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

             В данном случае, элемент <time> предназначен содержать одну единицу информации. Но большинство семантических элементов HTML5 не такие: они служат для обозначения блоков содержимого большего размера. Например, элемент <nav> обозначает набор ссылок для перемещения по содержимому, элемент <footer> в коде обрамляет нижний колонтитул страницы и т.д.

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

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

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

             Как улучшить SEO с помощью семантики HTML5

             В этом руководстве мы узнаем, что такое семантика HTML5 и как она помогает улучшить SEO сайта.

             Семантика была неотъемлемой частью HTML. Но ей стали уделять должное внимание только после появления HTML5.

             Но все HTML-теги с определенным значением являются семантическими Например, заголовки (h2>, <h3>, <h4>, <h5>, <h5>, <h6>), упорядоченные и неупорядоченные списки (<ol>, <ul>, <li>), абзацы (<p>), изображения (<img>), таблицы (<table>, <thead>, <tbody>, <tfoot>, <tr>, <td>), элементы формы (<form>, <fieldset>, <label>, <input>, <textarea>) и ссылки (<a>).

             HTML5 добавил в язык несколько новых семантических тегов: <figure>, <header>, <footer> (блочные теги) и <strong>, <em>, <mark> (строчные теги). Но по-настоящему важным стало введение четырех секционных элементов: <article>, <aside>, <nav> и <section>. Они позволяют создать более детальную архитектуру каждой HTML-страницы.

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

             1. Используя семантику HTML
             2. С помощью расширенных сниппетов (структурированных данных).

             Не все семантические теги HTML5 предназначены для одной и той же цели. Существует три их основных типа:

             • Блочные секционные элементы.
             • Блочные несекционные элементы.
             • Строчные элементы.

             Блочные секционные элементы формируют структуру документа, которую могут понять поисковые роботы. К секционным HTML-тегам относятся:

             1. <article> — предназначен для разметки отдельных публикаций, таких как статьи или обзоры.
             2. <section> — используется для разметки блоков контента, которые логически связаны друг с другом. Например, контента с вкладками;
             3. <aside> — для структурирования сносок и меток.
             4. <nav> — для элементов навигации.

             Тег <main> не является секционным элементом. Но это все равно семантический тег. Его можно использовать только один раз на каждой HTML- странице.

             Секционные элементы создают разметку контента, которая находится вне структуры страницы. Поэтому для них можно задавать свои заголовки (<h2>, <h3>, <h4>, <h5>, <h5>, <h6>), шапки (<header>) и подвалы (<footer>). Эти теги относятся только к секционному элементу и не являются частью страницы. Вот пример правильной разметки на HTML5.

             В примере видно, что можно использовать отдельный тег <h2> для элемента <article>. Он существует вне структуры страницы, потому что нельзя использовать два тега <h2> на одной странице.

             Также у тега <article> могут быть свои <header> и <footer>, которые не входят в DOM страницы.

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

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

             Существуют инструменты, которые помогают создать логическую структуру веб-страницы. HTML Outliner – это инструменты, которые анализируют структуру веб-страницы.

             Они реализованы в виде онлайн-сервисов, которые помогают определить потенциальные проблемы в структуре HTML-документа. Например, отсутствующие заголовки.

             Также доступны специальные расширения для браузера. Например, HeadingsMaps для Firefox или HTML5 Outliner для Chrome. Они позволяют анализировать структуру HTML-документа с любого URL-адреса. Таким образом, можно быстро проверить, какую семантику HTML5 используют ваши конкуренты.

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

             Текстовые блоки веб-страницы должны быть легко читаемыми. Это помогает поисковым системам лучше понимать контент. Теги, используемые для «разбиения» контента, являются семантическими. К ним относятся: <img>, <figure>, <video>, <audio>, <ul>, <ol> и другие.

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

             Данная публикация представляет собой перевод статьи «A Guide to HTML5 Semantics for Better SEO» , подготовленной дружной командой проекта Интернет-технологии.ру

             семантических элементов HTML5 объяснил

             Семантические HTML-элементы — это те, которые четко описывают их значение для человека и машины.

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

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

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

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

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

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

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

             Список новых семантических элементов

             Семантические элементы, добавленные в HTML5:

             Такие элементы, как , , , , и действуют более или менее как

             Пример макета семантического элемента от w3schools

             Зачем использовать семантические элементы?

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

             Хотя во втором блоке кода используются несемантические элементы:

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

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

             В программировании семантика относится к , что означает фрагмента кода — например, «какой эффект имеет выполнение этой строки JavaScript?», Или «Какую цель или роль имеет этот элемент HTML» (а не «как он выглядит?».)

             Семантика в JavaScript

             Семантика в CSS

             В CSS рассмотрим стилизацию списка с или элементами, представляющими различные виды фруктов. Знаете ли вы, какая часть DOM выбирается с div> ul> li или .fruits__item ?

             Семантика в HTML

             Например, в HTML элемент

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

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

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

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

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

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

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

             Семантические элементы

             Это , примерно из примерно 100 доступных семантических элементов:

             Узнать больше

             HTML5 поставляется с рядом семантических тегов, которые позволяют вам определить назначение элемента на вашем сайте. Они не влияют на то, насколько хорошо работает сайт (для большинства людей) или на его SEO. Так стоит ли вообще использовать теги HTML5? И если да, то как семантические теги HTML5 работают в Webflow?

             Краткий ответ: Да. Использовать семантические элементы HTML5

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

             И если вы «не слишком обеспокоены» доступностью вашего сайта, подумайте на минуту, что, по данным Бюро переписей США, примерно каждый пятый человек имеет какую-либо форму инвалидности.

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

             HTML5 и семантика

             Опубликованный в октябре 2014 года, стандарт HTML5 в настоящее время поддерживает почти универсальных браузеров. Все современные браузеры поддерживают HTML5 — некоторые старые браузеры, такие как Internet Explorer, не поддерживают.

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

             Хорошо, так что такое семантика? А что такое семантические элементы?

             Итак, в веб-дизайне семантический элемент — это элемент, который имеет внутреннее значение и передает его как браузеру, так и разработчику.

              
             Похожие публикации:

             1. Как играть в телефон
             2. Как избежать блокировки нетфликс
             3. Как открыть рабочий стол с другого жесткого диска
             4. Как создать электронную почту на телефоне яндекс

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

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

             Имя *

             Email *

             Сайт

             Комментарий *

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