Правила html5

Оглавление:

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

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

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

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

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

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

  • Содержание:
  • 1. Элемент
  • 2. Элемент
  • 3. Элемент
  • 4. Элемент
  • 5. Элемент
  • 6. Элемент
  • 7. Элемент
  • 8. Элемент
  • 9. Элемент
  • 10. Элемент
  • 11. Элемент
  • 12. Элемент
  • 13. Элемент
  • 14. Элемент
  • 15. Элементы для описания Восточно-Азиатских символов

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

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

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

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

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

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

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

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

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

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

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

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

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

Элемент не может быть потомком таких элементов как , , , или .

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

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

10. Элемент

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

11. Элемент

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

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

12. Элемент

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

13. Элемент

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

14. Элемент

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

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

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

Элементы , , и не относятся ни к одной категории контента.

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

html5book.ru

Стандарты кодирования в HTML5

Зачастую веб-разработчики даже не подозревают о существовании определенных стандартов кодирования в HTML. Однако в период с 2000 по 2010 годы многие веб-разработчики перешли с HTML на XHTML. При этом XHTML вынудил разработчиков писать валидный и «хорошо сформированный» код. HTML5 же, когда дело доходит до валидации кода, допускает некоторую небрежность.

Тем не менее, единообразие по стилю облегчит другим понимание вашего HTML кода.

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

Всегда следите, чтобы ваш код был аккуратным, чистым и хорошо сформированным.

Используйте корректный тип документа

На первой строке всегда декларируйте тип документа:

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

Имена элементов пишите маленькими буквами

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

  • Смешение больших и маленьких букв в именах тегов считается плохой практикой
  • Разработчики обычно используют маленькие буквы (как в XHTML)
  • Написание в нижнем регистре выглядит чище
  • В нижнем регистре легче писать

Закрывайте все HTML элементы

В HTML5 вы не обязаны закрывать все элементы (например, элемент

). Тем не менее, мы все же рекомендуем закрывать все HTML элементы.

Закрывайте пустые HTML элементы

В HTML5 закрывать или нет пустые элементы зависит от желания веб-разработчика.

Тем не менее, закрывающая косая черта (/) ОБЯЗАТЕЛЬНА в XHTML и XML.

Если ожидается, что к вашей веб-странице будут обращаться XML приложения, то в пустых HTML элементах лучше использовать закрывающую косую черту!

В именах атрибутов используйте маленькие буквы

В HTML5 при написании имен атрибутов можно смешивать большие и маленькие буквы.

Мы рекомендуем в именах атрибутов всегда использовать только маленькие буквы. Это вызвано следующими причинами:

  • Смешение больших и маленьких букв в именах атрибутов считается плохой практикой
  • Разработчики обычно используют маленькие буквы (как в XHTML)
  • Написание в нижнем регистре выглядит чище
  • В нижнем регистре легче писать

Заключайте значения атрибутов в кавычки

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

  • Смешение больших и маленьких букв в значениях считается плохой практикой
  • Значения в кавычках легче читать
  • Вы ДОЛЖНЫ заключать в кавычки, если в значениях есть пробелы

Атрибуты изображений

При определении изображений всегда используйте атрибут «alt». Этот атрибут важен, когда изображение по какой-то причине не отображается.

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

Пробелы и знак равно

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

Избегайте длинных строк кода

При использовании HTML редактора, неудобно читать HTML код, если приходится прокручивать окно влево или вправо.

Следует стараться, чтобы строка кода в длину не превышала 80 символов.

Пустые строки и отступы

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

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

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

Не используйте ненужные пустые строки и отступы. Нет необходимости ставить отступ перед каждым элементом.

Пропускать или нет и ?

По стандарту HTML5 тег и тег могут не использоваться.

Следующий код согласно стандарту HTML5 считается валидным:

Однако мы не рекомендует пропускать теги и .

Элемент — это корень документа. Это рекомендованное место для определения языка страницы:

Декларация языка страницы важна как для специализированных приложений (например, программ чтения с экрана), так и для поисковых систем.

Кроме этого, если не написать тег или тег , то это может сломать структуру DOM и XML приложения. А пропуск тега к тому же может привести к ошибками в старых браузерах (IE9).

Пропускать ли тег ?

Согласно стандарту HTML5 тег может не использоваться.

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

Вы можете снизить сложность структуры HTML, пропустив тег :

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

Метаданные

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

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

Установка вьюпорта (окна просмотра)

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

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

Следует всегда использовать элемент управления вьюпортом в следующей форме на всех веб-страницах:

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

Часть width=device-width устанавливает ширину страницы в соответствии с шириной экрана текущего устройства (которая будет разной в зависимости от используемого устройства).

Часть initial-scale=1.0 устанавливает начальный уровень увеличения, когда страница впервые загружается браузером.

Ниже вы можете увидеть пример веб-страницы на экране смартфона с установленным мета тегом вьюпорта и без него:

Страница без метатега вьюпорта

Страница с мета тегом вьюпорта

HTML комментарии

Короткий комментарий должен писаться на одной строке:

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

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

Таблицы стилей

Используйте простой синтаксис для подключения внешних каскадных таблиц стилей (атрибут type не нужен):

Короткие правила могут записываться в сжатом виде в одну строку:

Длинные правила следует записывать на нескольких строках:

  • Открывающие скобки размещайте на одной строке с селектором
  • Используйте один пробел перед открывающими скобками
  • Для отступов используйте два пробела
  • После каждой пары свойство-значение, включая последнюю, ставьте точку с запятой
  • Кавычки используйте только со значениями, содержащими пробелы
  • Закрывающие скобки пишите на новой строке без отступа
  • Старайтесь, чтобы длина записи на одной строке была не больше 80 символов

Загрузка JavaScript в HTML

Для загрузки внешних скриптов Javascript используйте простой синтаксис (атрибут type не нужен):

msiter.ru

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

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

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

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

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

Честно говоря, это неправильно: — это не обёртка. Элемент определяет смысловую секцию содержимого для создания структуры документа. Он должен содержать заголовок. Если вы ищете элемент для того чтобы обернуть в него всю страницу (в стиле HTML или XHTML), подумайте, не применить ли стили непосредственно к элементу , как описано у Крока Кеймена. Если же вам всё ещё нужна дополнительная обёртка, используйте

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

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

Используйте и осознанно

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

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

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

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

Злоупотребление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавить здесь нечего: это совсем неправильно. Мы можем спорить до посинения насчёт того, должно ли лого находиться внутри

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

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

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

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

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

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

Дело в том, что в HTML5 не нужно добавлять атрибут type для элементов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[email protected], статья хорошая — понятное дело, хочется перевести.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

web-standards.ru

Смотрите так же:

  • Пример заявок на субсидию Заполнение заявки на предоставление субсидий за счет средств областного бюджета в электронном виде для предварительного просмотра Заполните поля электронной формы (обязательные для заполнения поля выделены звездочкой). В нижней части […]
  • Возврат из функции php Совет: возврат нескольких значений из функции Вообще говоря PHP не даёт нам возможности вернуть несколько значений из функции. В то же время мы можем вернуть массив данных и разобрать его различными способами. В данном примере функция […]
  • Вторжение между ног Правила съема Вторжение между ног. Правила съема Считается, что знакомиться на улице не принято. Однако если вы научитесь делать это правильно, девушка сама с удовольствием предложит вам общение. Не думайте, что яркая и интересная красотка никогда не […]
  • Состав суда в надзорной Состав суда в надзорной Пункт 58 ст. 5 УПК РФ определяет участников как лиц, принимающих участие в уголовном процессе. txt fb2 ePub html на телефон придет ссылка на файл выбранного формата Шпаргалки на телефон — незаменимая вещь при […]
  • Опека в кропоткине УСЫНОВЛЕНИЕ В РОССИИ Интернет-проект Министерства образования и науки РФ Департамент государственной политики в сфере защиты прав детей А Абинский район Апшеронский район Б Белоглинский район Белореченский район Брюховецкий […]
  • Помогу оформить кредит без пенсионных отчислений ФОРУМ ГРУППЫ ПРИКЛАДНОЙ ИНФОРМАТИКИ Меню навигации Пользовательские ссылки Информация о пользователе Вы здесь » ФОРУМ ГРУППЫ ПРИКЛАДНОЙ ИНФОРМАТИКИ » ну вот и пришла сессия завтро в 14:00 на авроре » микрокредиты без залога и без […]

Комментарии запрещены.