Пытаюсь понять семантику HTML5

[alexpop]

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

Мне интересно ваше мнение насчет моей трактовки. И как вы понимаете этот вопрос.

Демо-страница находится здесь

Целиком текст на форум не влазит, вот фрагмент:

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

Здесь я не буду рассказывать о новом функционале, сосредоточусь только на тегах семантических элементов типа: article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu, nav, section...

[rediskavet]

Да, интересно. С приходом html5 уже ни кто не сможет утверждать что семантика это пустое слово.

Сколько по вашему мнению может быть тегов nav на странице? В спецификации как я понял(оригинал не читал, только переводы) советуют использовать только один раз на странице, для главной навигации. В других местах видел предложения ссылки следующая, предыдущая и номера страниц 1,2,3,4 и т.п. тоже заверстывать в тег nav. То есть по второй теории правило с одним тегом nav не однозначно. Что думаете по этому поводу?

[alexpop]

Да, интересно. С приходом html5 уже ни кто не сможет утверждать что семантика это пустое слово.

Сколько по вашему мнению может быть тегов nav на странице? В спецификации как я понял(оригинал не читал, только переводы) советуют использовать только один раз на странице, для главной навигации. В других местах видел предложения ссылки следующая, предыдущая и номера страниц 1,2,3,4 и т.п. тоже заверстывать в тег nav. То есть по второй теории правило с одним тегом nav не однозначно. Что думаете по этому поводу?

Признаюсь, я не смог найти в интернете ничего "железного" насчет разметки, поэтому и решил читать оригинал. Вот, что буквально написано про спецификация nav:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

Элемент nav отображает раздел страницы, который линкуется с другими страницами или частями самой страницы: раздел с навигационными линками. (В общем это и так понятно)

А далее иду комментарии:

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

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

Следующие три примера кода иллюстрируют случаи, когда используется 1 nav тег, при том, что есть два блока с ссылками, но лишь однин блог - навигационный. Второй пример использует ДВА ТЕГА nav (!) один блок ссылок на другие страницы сайта, а второй на блок ссылок на самой странице. И третий пример, который вообще не является списком, а просто какой-то текст с контекстыми ссылками.

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

[Vlad]

У вас ошибки имеются в блоке "Почему теги элементов строчные, а не блочные?". В спецификации HTML5 не указано, какими должны быть теги nav, article, header и др. Там вообще другая модель систематизации. Строчные же они в браузерах, которые не поддерживают новые теги. Если возьмёте, допустим, Firefox4-5, в нём уже другой движок рендера и теги HTML5 блочные.

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

[alexpop]

У вас ошибки имеются в блоке "Почему теги элементов строчные, а не блочные?". В спецификации HTML5 не указано, какими должны быть теги nav, article, header и др. Там вообще другая модель систематизации. Строчные же они в браузерах, которые не поддерживают новые теги. Если возьмёте, допустим, Firefox4-5, в нём уже другой движок рендера и теги HTML5 блочные.

Да, согласен. Разные броузеры трактуют по-разному. Я так назвал для условности. Я обратил на это внимание, но не смог подобрать определение из известных. Могу поправить, только не знаю, на что... ))

Edited July 23, 2011 by alexpop

[Vlad]

Не смогли подобрать определение для чего?

[alexpop]

Не смогли подобрать определение для чего?

Спасибо! Мой косяк. Я поправил там текст на следующий:

На самом деле, это вопрос возник у меня от собственной невнимательности. Влад Мержевич на форуме forum.htmlbook.ru открыл мне глаза. Дело в том, что многие разработчики в CSS явным образом прописывают display:block;. Из чего я сделал поспешный вывод, что это инлайн-контейнер. Не удосужившись проверить это, я решил, что так оно и есть. Тем не менее, элементы article, aside, details, figcaption, figure, footer, header, hgroup, menu, nav, section (возможно, еще какие-то) рендерятся современными броузерами как блочные контейнеры. Но! IE до 9 версии действительно трактуют как строчный контейнер. Это и стало причиной моего заблуждения.

Edited July 24, 2011 by alexpop

[SelenIT]

Полностью согласен с "Базовыми принципами..." и "Последним словом" (по крайней мере, как я это понимаю на текущий момент). Есть сомнения насчет figure c заголовками "просто для того, чтоб они не попали в outline" — всё-таки основная задача figure не в этом, а в "инкапсуляции" иллюстрации (или чего-то подобного) с подписью (которая figcaption), здесь я такой функции не вижу.

И насчет <menu> — насколько я понимаю, формально валидацию-то оно проходит, про недоподдержку — это лишь warning. А пример, имхо, удачный!

[Softlink]

А пример, имхо, удачный!

Так-то вроде да, все правильно расписано. Только вот зачем версталось все на дивах? На html5-теги никто же вроде бы не запрещает вешать стилевое оформление? Или задача так сверстать не ставилась?

[SelenIT]

Судя по "базовым принципам", задача ставилась скорее обратная — по-максимуму разнести семантику и оформление по разным, условно говоря, слоям разметки

[alexpop]

Есть сомнения насчет figure c заголовками "просто для того, чтоб они не попали в outline" — всё-таки основная задача figure не в этом, а в "инкапсуляции" иллюстрации (или чего-то подобного) с подписью (которая figcaption), здесь я такой функции не вижу.

Действительно, если верить спецификации, то для картинок figure - самое оно. Но вместе с этим, в спецификации указывается более широкий функционал:

The figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

Что я бы перевел так:

Элемент figure представляет собой некий поточный контент, (опционально с подписью), который является самодостаточным и обычно рассматривается как отдельный объект в основном потоке документа.

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

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

Так-то вроде да, все правильно расписано. Только вот зачем версталось все на дивах? На html5-теги никто же вроде бы не запрещает вешать стилевое оформление? Или задача так сверстать не ставилась?

Именно по этой причине - если бы я изловчился, и вместо дивов использовал теги разметки, то как бы я поменял потом семантику, если бы это нужно было? Вот, например – сайт, ну скажем, новостной портал, или просто блог имеет 2-3 макета страниц. А контент в этих макетах очень разный, и акценты так-то разные могут быть. Если бы весь макет "висел" на тегах семантики, то тогда все бы страницы были семантически одинаковы. Как только ты привязал семантику к каркасу - сразу "убил" возможность пользоваться разметкой по своему усмотрению на разных страницах имхо. Что мы делам в этом случае? Оставляем те-же 2-3 каркаса, и делаем Семантические модификации, например.

Или вот с чем еще можно сравнить: Как CSS отделяет "визуал" от "Содержимого" сайта, так и Семантические теги позволяют отделить "Смысл" от "Визуала" (не факт, что нужно, но бывает. Под визуалом я понимаю не "яркую и веселую картинку" сайта, а каркас (CSS + HTML). Иногда позволяют свести "Содержимое" и "Смысл". Вместе.

Еще раз подчеркну - я специально "разломал" макет, чтобы проверить возможности. И когда я сделал дублирующую страницу на заголовках, ровно с тем-же дизайном, но с совершенно иной семантикой - у меня ушло на это 2 минуты. Убил контейнеры семантической разметки и поменял h1 на h2 и h3 кое-где. И все. А если бы констукция висела на этих тегах? А?

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

Edited July 25, 2011 by alexpop

[SelenIT]

Сегодня удачно вспомнили статью Ричарда Кларка (одного из авторов html5doctor.com), где тоже говорится про figure:

<figure> should be used only when referenced in a document or surrounding sectioning element. I think it’s fair to say that your logo is rarely going to be referenced in such a way.

По-моему, это тоже аргумент против figure для блока в левом верхнем углу: на него ж ниоткуда не ссылаются, скорее это именно что аналог логотипа...