barmaley_exe Jul 27 2011 at 23:17

Избегаем распространенных ошибок в HTML5 разметке

8 min

120K

HTML*

Translation

+119

Comments 92

WizardBox Jul 28 2011 at 00:06

А не было бы более корректно заменить «Не каждое изображение фигура» на «Не каждое изображение иллюстрация». А «Ваш логотип — не фигура» на «Ваш логотип — не иллюстрация»

barmaley_exe Jul 28 2011 at 00:10

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

В <figure> может быть заключено видео, аудио, графики (в SVG, например), цитата, таблица, блок кода, стихотворение или любая комбинация перечисленного.

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

tenshi Jul 28 2011 at 09:23

проиллюстрирую свою позицию следующей цитатой: «Иллюстрация (от лат. illustratio — освещение, наглядное изображение), 1) объяснение с помощью наглядных примеров.»

barmaley_exe Jul 28 2011 at 09:35

Это глагол, а нам нужно существительное. Лично у меня иллюстрация как существительное ассоциируется только с рисунками.

tenshi Jul 28 2011 at 11:39

в качестве иллюстрации приведу ещё пару ссылок:
dic.academic.ru/dic.nsf/enc3p/307662
lurkmore.ru/%C2%E7%E0%E8%EC%EE%E8%F1%EA%EB%FE%F7%E0%FE%F9%E8%E5_%EF%E0%F0%E0%E3%F0%E0%F4%FB

barmaley_exe Jul 28 2011 at 11:57

Ну да, фигура не лучший вариант. Как бы то ни было, я уже заменил её на <figure>.

UFO just landed and posted this here

barmaley_exe Jul 28 2011 at 00:16

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

UFO just landed and posted this here

barmaley_exe Jul 28 2011 at 00:45

Рассмотрим такой пример:
Профессор X изобрел *чудо-штуку*, приложил к ней инструкцию и раздал бесплатно всем людям. Люди поленились прочитать инструкцию и начали во всю пользоваться этой чудо-штукой, что привело к печальным последствиям. Кто виноват?

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

UFO just landed and posted this here

barmaley_exe Jul 28 2011 at 09:16

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

KaLGaN Jul 28 2011 at 17:02

Плохие верстальщики значит, если спек не читают…

vanxant Jul 28 2011 at 17:12

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

dmitriid Jul 28 2011 at 18:01

Так и есть :) В w3c, по-моему, реальный мир не видели уже лет 10, точно :)

vanxant Jul 28 2011 at 17:11

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

remal Jul 28 2011 at 17:35

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

HeavyWave Jul 28 2011 at 04:45

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

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

GearHead Jul 28 2011 at 05:29

header может быть и у статьи, и у страницы, и у секции. а после статьи понятно, что использовать его надо только тогда, когда нужно подчеркнуть структурно кусок кода. ИМХО здесь мало чего нелогичного.

Mithgol Jul 28 2011 at 09:14

Профессор X изобрёл чудо-штуку, приложил к ней инструкцию и раздал бесплатно всем людям. Люди поленились прочитать инструкцию и начали вовсю пользоваться этой чудо-штукой, что привело к печальным последствиям. Кто виноват?

Отчасти виноваты другие Люди X, которые не сказали ему вовремя: «Ты слишком идеалистичен, Чарльз».

remal Jul 28 2011 at 01:56

Дело в том, что огромное кол-во верстальщиков — безрукие идиоты, место которым за стойке в Макдональдсе, а не сайты верстать.

UFO just landed and posted this here

isden Jul 28 2011 at 13:02

> Если ошибки уж очень распространённые, то, может, дело не в тех, кто эти ошибки совершает, а в замысловатости спецификации?

Имхо, дело просто в непривычности подхода к разметке текста (структурная разметка vs. семантическая). Многие говорят что HTML5 вместо упрощения сильно усложняет жизнь. Но имхо, если разобраться в основах (т.е. зачем вся эта семантика и что это такое) — все становится значительно проще и понятнее.

fogx Jul 28 2011 at 03:41

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

А сейчас что? Ну вставил я в все свои 30 ссылок, а логотип обозвал фигурой, что дальше? Где мне найти хоть один бровзер, программу или онлайн-сервис, который на это ругнется? Для кого вообще это все делается? Для гугла, чтобы он лучше индексировал? Окей, тогда дайте мне загрузить мою страничку в гугл и посмотреть, как он ее видит. Или для мобильного бровзера, который будет вырезать «неважные» по его мнению элементы? Хорошо, дайте мне на это посмотреть!

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

barmaley_exe Jul 28 2011 at 09:24

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

Выше была приведена ссылка на статью о document outline, там в конце есть ссылки на outliner'ы. С их помощью Вы можете посмотреть на схему своего документа и оценить, насколько точно она передает его структуру.

BekoBou Jul 28 2011 at 00:33

Вадим pepelsbey Макеев более как-то красивее, качественнее и раньше перевёл и опубликовал данную статью.

barmaley_exe Jul 28 2011 at 00:40

Да, увы, я заметил её только после публикации этой статьи (RSS фид обновился только спустя несколько часов).
Если хабрасообщество решит, что эта статья не нужна, я, так и быть, уберу ее в черновики.

cbone Jul 28 2011 at 13:35

Оставляйте. Мне пригодилась.

Sardar Jul 28 2011 at 01:04

<input type="email" name="email" required />
Тут либо лишний '/', либо на required парсер должен споткнуться. Неясно зачем смешивать синтаксисы HTML и более строгого XML. Надеюсь автор просто ошибся.

KY3bKA Jul 28 2011 at 02:55

Ребят, я все понимаю! Но правда достало, на кой черт, этот ваш XML и XHTML нужен?
Я веду курсы по HTML вот уже 3 года.До этого долгое время работал в компании которая одной из первых представила комерческую CMS/DocFlow систему на CeBIT. И я правда не понимаю!

Объясните мне идиоту, если не трудно, нахрена нужны правила XML применительно к HTML'ю?

На мой взгляд XHTML это бастрад «странного стандарта — XML» и W3C, который, слава богу, явно, заканчивает свою карьеру.

hf35 Jul 28 2011 at 09:03

для порядка он нужен.

dmitriid Jul 28 2011 at 18:02

Не нужен он для порядка.

dlancer Jul 28 2011 at 09:04

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

arkanum Jun 22 2015 at 13:11

Начинай изучать сейчас, чтобы не изучать потом и больше. :)

torbasow Jul 28 2011 at 09:42

Для обеспечения единства синтаксиса с другими языками разметки — SVG, XSLT, XSD, XUL, XBL, MathML, RSS… Их можно легко и ясно преобразовывать друг в друга, буде возникнет нужда. А неэксэмэльконформный HTML — не пойми что и сбоку бантик.

vanxant Jul 28 2011 at 17:15

И что? Кому надо что-то преобразовать — возьмет и напишет нормальный парсер. Почему из-за него должен страдать миллион верстальщиков?

torbasow Jul 28 2011 at 18:00

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

vanxant Jul 28 2011 at 18:47

Меня как программиста выбешивает необходимость заключать в кавычки числа, идентификаторы и члены перечислений. Есть синтаксис, принятый в подавляющем большинстве языков программирования, включая Javascript, PHP, CSS, нормальном HTML и т.п. и т.д., которые в реальных CMS идут сплошным комком. Запись вида
<img id=img1 width=42 align=right alt=«Картинко»>
— синтаксически нормальна. Но этот же элемент в стиле XHTML (с кавычками) вызывает почти физическое неприятие, руки сами тянутся убрать лишние символы. И главное, ради чего? Потому что кто-то там настолько криворук, что не может распарсить числа без кавычек?

Roler Jul 28 2011 at 22:47

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

vanxant Jul 29 2011 at 00:08

o rly? например как?

torbasow Aug 3 2011 at 15:46

Ни в Javascript, ни в PHP такое — «id=img1» — не прокатит. А width и тем более align — это презентационные особенности, им в HTML вообще не место. Если Вам угодно писать архаичный HTML, тогда не удивительно, что Вам для этого хочется использовать архаичный синтаксис.

Потому что кто-то там настолько криворук, что не может распарсить числа без кавычек?

Потому что с ходу не ясно — числа там или строка, да ещё с пробелами. Нужно учитывать, какой именно атрибут, какие значения он предполагает. А он ведь может быть ещё и нестандартный…

Между прочим, в PHP нет удовлетворительного по возможностям встроенного парсера HTML, а сторонний PHP Simple HTML DOM Parser занимает 53 килобайта (и на практике всё равно не со всякой страницей справляется).

vanxant Aug 3 2011 at 16:36

У как всё запущено. Вы сначала разберитесь, зачем нужны width и align в img:)
По остальному тоже смешно, если очередной школьник, тырящий контент для своего говносайта под сапу настолько туп, что не может найти в интернете нормальный парсер html — это исключительно его трудности, но никак не верстальщков сайта-жертвы:)

torbasow Aug 3 2011 at 17:29

Я, как бы, уже семнадцать лет не школьник. Возможно поэтому я не пишу картинке выравнивание в атрибуте; если мне нужен поплавок, я делаю его надлежащим образом — через стили. А Вы так и пишете align? Окститесь, XXI век давно наступил.

vanxant Aug 3 2011 at 18:15

Я не знаю что и как вы там делаете, но вы явно далеки от продакшена.
Понимаете, в оформлении сайтов тэг img практически не используется, ну разве что кроме логотипа. Всё оформление идёт через background-image, да, вот там стили, классы и прочая прочая, чтобы повторяющиеся элементы оформления были описаны один раз.
Тэг img — это тег содержания, которое на каждой важной странице сайта уникально. Вставить картинки в статью или там вывесить фотки товара — вот его основное использование. И вот тут никаких классов быть не может, потому что в каждой статье свои уникальные картинки, и где им нужно быть — слева, справа или там по центру — решает девочка — контент-менеджер. Которая скорее всего какой-нибудь там филолог, она правильно расставляет запятые с жесткими переносами и знает языков эдак 5 — но названия всех из них заканчиваются на "-ий". И в своей работе она использует какой-нибудь там TinyMCE (хотя и не знает такого слова), потому что его прикрутили в админку, потому что он похож на Word и даже девочки-филологи способны его освоить. Ну а то что генерируемый им код не блещет чистотой — так зато работает как надо.
(Кстати, сейчас проверил: свежий TinyMCE вместо align=right наконец-то стал использовать более современный style=«float: right», так что я можно сказать зря на него грешил).

torbasow Aug 8 2011 at 07:59

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

И: если расположение каждой картинки (и говоря шире — элементов содержания вообще) на каждой странице уникально и никаким закономерностям не подчиняется, то это дрянная, беспорядочная, безвкусная вёрстка — вот что я скажу.

torbasow Aug 3 2011 at 16:26

…И вообще программисту по-хорошему незачем расставлять все эти кавычечки и даже думать о них (или об их отсутствии, что, по-моему, заморочней). Это устаревшая методика — писать HTML-код прямо из скрипта. Шаблонизаторы и фреймворки должны этим заниматься. А они будут друг друга замечательно понимать, если в них закладывать XML-синтаксис.

vanxant Aug 3 2011 at 16:41

Если закладывать XML-синтаксис между фреймворком и шаблонизатором, то они будут замечательно тормозить. И вообще подобные архитектурные решения обычно указывают на серьезные заболевания головного мозга придумавшего это программиста.
И да, веб-программисту необходимо прекрасно знать html+css и даже приходится периодически самому верстать некие блоки html-кода. И никакой волшебный шаблонизатор за него это не сделает.

torbasow Aug 3 2011 at 17:34

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

dmitriid Jul 28 2011 at 18:04

встречаем тэг svg, переключаемся в строгий svg-парсер. видим закрывающий тэг svg, переключаемся в нестрогий html-парсер. В чем проблема-то? ;)

torbasow Jul 29 2011 at 07:40

Чего ради мешать в одном документе разные синтаксисы? С точки зрения XML разница между этими языками только в пространстве имён — и это замечательно: можно применять одни методы и преобразовывать одно в другое посредством XSLT. XML великолепен своим универсализмом, так зачем раздирать это единство?

8bitjoey Jul 28 2011 at 12:03

Есть множество мнений, например
XHTML как морская свинка — и не морская и не свинка.
12 причин ненавидеть XHTML
55 причин использовать XHTML-CSS при создании сайтов
Ответ на «15 преимуществ» XHTML и 2 вопроса к читателям
XHTML 2 против HTML 5
Рабочая группа XHTML 2 прекращает свою работу в конце 2009 года. W3C бросает все силы на HTML 5!
XHTML умер? Да здравствует XHTML!

torbasow Jul 28 2011 at 14:01

«12 причин», видимо, писались как пародия. Особенно доставило в качестве недостатка XHTML: «HTML гораздо сложнее парсить (автоматически копировать) чем XHTML, который как раз и предназначен для облегчения парсинга».

mihaild Jul 28 2011 at 03:03

А в чем проблема? Парсер видит атрибут /, не знает, что это такое и с чистой совестью игнорирует.

torbasow Jul 28 2011 at 09:33

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

TheShock Jul 28 2011 at 09:36

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

torbasow Jul 28 2011 at 13:53

Подсказки человеку — это дело для IDE. А для машины этот слэш — мусор.

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

diamant Jul 28 2011 at 15:01

В таком случае и символы перевода каретки и новой строки для машины — мусор.
Свои сайты вы пишете в одну строку?

torbasow Jul 28 2011 at 16:30

Некоторые фрагменты приходится. Смотрите мой коммент ниже.

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

diamant Jul 28 2011 at 16:41

Многие IDE умеют редактировать XML в виде дерева — на выходе всё будет в одну строку.

torbasow Jul 28 2011 at 18:00

А посоветуйте.

dmitriid Jul 28 2011 at 18:08

Altova XMl Spy, если не ошибаюсь

torbasow Jul 30 2011 at 12:18

Платный же. Идея потратить 400—800 евро меня как-то мало возбуждает.

diamant Jul 28 2011 at 18:24

Eclipse?

Volshebnyi Jul 28 2011 at 13:05

Отступы и пробелы тоже мусор.

torbasow Jul 28 2011 at 13:57

И это проблема. Например, внутри инлайнового элемента. Неужто Вам не приходилось писать теги в одну строчку подряд, чтобы избежать появления промежутков между блоками? Выглядит это безобразно, а что делать? Писать ради оформления кода font-size: 0? Если бы ещё все браузеры это нормально понимали.

Inquirer Jul 30 2011 at 08:16

white-space:nowrap (если забить на седьмой ие)

torbasow Jul 30 2011 at 12:43

И что? Попробуйте:

<p style="white-space: nowrap;">
	<span style="background-color: pink;">Слово</span>
	<span style="background-color: pink;">Слово</span>
</p>

В Firefox 5 я вижу между словами промежуток.

TheShock Jul 28 2011 at 09:24

Тут либо лишний '/', либо на required парсер должен споткнуться

Согласно html5 незакрытые теги можно закрывать таким образом.

Dragonizer Jul 28 2011 at 01:09

<script type="text/javascript" src="js/scripts" /></script>

<script src="js/scripts" /></script>

В оригинале этого не было. ;)

pepelsbey Jul 28 2011 at 03:32

В оригинале было много ошибок — почитайте комментарии, просто их исправили.

barmaley_exe Jul 28 2011 at 09:29

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

rimmer333 Jul 28 2011 at 01:33

Ыыых, и эти люди, как говорится… Ссылка на flowchart: html5doctor.com/happy-1st-birthday-us/#flowchart (сама перематывает в тот самый низ поста).

pepelsbey Jul 28 2011 at 03:33

Альтернативный перевод: web-standards.ru/articles/avoiding-html5-mistakes/

bulka_by Jul 28 2011 at 04:05

Пользователь BekoBou уже как бы указал на данную статью выше, зачем повторятся-то?

pepelsbey Jul 28 2011 at 04:09

Пардон, не заметил.

interrupt_controller Jul 28 2011 at 06:22

думаю, чтобы люди научились пользоваться html5 нужно ужесточить валидацию

VolCh Jul 28 2011 at 08:22

Валидацию семантики сложно производить, по-моему.

isden Jul 28 2011 at 13:10

Да вроде не особенно. Зародыш подобного я видел некоторое время назад в SEO тулзах в панели управления GoDaddy. Оно там, например, умело разбирать что написано в тэгах <h?> и как это относится к собственно контенту.
Т.е. все упирается в анализ текста в семантических блоках (и структуру этих блоков) имхо.

ytriffy Jul 28 2011 at 12:50

>Избегаем распространенных HTML5 ошибок
Избегаем распространенные ошибки в HTML5

Fixed.

barmaley_exe Jul 28 2011 at 13:08

В HTML5 нет ошибок. По крайней мере, здесь обсуждаются не они.

fomichev Jul 28 2011 at 17:19

«В разметке на языке HTML5», «за сайтами в галерее HTML5», «сайтов на HTML5» и пр. «HTML5 ошибок» — это калька с английского, а не перевод.

barmaley_exe Jul 28 2011 at 17:50

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

UFO just landed and posted this here

klierik Jul 28 2011 at 17:12

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

klierik Jul 28 2011 at 17:14

парсер съел

 <div role="main">
    <!-- Контент страницы -->
  </div>
  <aside role="complementary">
    <!-- Дополнительный контент -->
  </aside>

crwin Jul 28 2011 at 17:21

www.w3.org/TR/wai-aria/roles#role_definitions

klierik Jul 28 2011 at 17:27

То есть если я правильно понял то прийдеться вешать на тот же чекбокс еще и role

<input type="checkbox" role="checkbox" />

А еще есть табы, списки, ссылки и ещё куча всего.
Если там описать все, то вес существенно пойдет в гору.

crwin Jul 28 2011 at 18:03

Html5 излишне повёрнут на семантике, может быть даже чересчур, поэтому там описывается всё что только можно. Использовать всё подряд не стоит, достаточно лишь указать для основных блоков — шапка, контент, навигация и футер, дальше уже по надобности и желанию.
На деле оказалось, что довольно удобно использовать role — раньше для описания для чего нужен этот div использовал комментарии, теперь всё «семантичнее» ©

dmitriid Jul 28 2011 at 18:07

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

<div role="rdf:header">...

и все будут счастливы.

нет. надо ввести новые теги, а потом сверху к этому еще докручивать rdf, goodrelations и толпу еще непонятно чего

equand Jul 28 2011 at 17:32

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

starodubcev Jul 28 2011 at 22:49

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