Как стать автором
Обновить

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

А не было бы более корректно заменить «Не каждое изображение фигура» на «Не каждое изображение иллюстрация». А «Ваш логотип — не фигура» на «Ваш логотип — не иллюстрация»
На мой взгляд, заменять фигуру на иллюстрацию не лучший шаг, т.к.
В <figure> может быть заключено видео, аудио, графики (в SVG, например), цитата, таблица, блок кода, стихотворение или любая комбинация перечисленного.
И если график или видео еще можно посчитать иллюстрацией, то вот аудиозапись или блок кода — вряд ли.
проиллюстрирую свою позицию следующей цитатой: «Иллюстрация (от лат. illustratio — освещение, наглядное изображение), 1) объяснение с помощью наглядных примеров.»
Это глагол, а нам нужно существительное. Лично у меня иллюстрация как существительное ассоциируется только с рисунками.
Ну да, фигура не лучший вариант. Как бы то ни было, я уже заменил её на <figure>.
НЛО прилетело и опубликовало эту надпись здесь
Это рекомендации по наполнению Вашей разметки смыслом. Цель всех этих шаманств — более подробно описать документ и его содержимое. В дальнейшем это может быть использовано поисковиками или специальными устройствами для людей с ограниченными способностями, например.
Ваша разметка будет по-прежнему работать, даже если она составлена из одних дивов, но возможность извлечения дополнительной метаинформации будет сильно ограничена.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Рассмотрим такой пример:
Профессор X изобрел *чудо-штуку*, приложил к ней инструкцию и раздал бесплатно всем людям. Люди поленились прочитать инструкцию и начали во всю пользоваться этой чудо-штукой, что привело к печальным последствиям. Кто виноват?

В нашем случае, никаких печальных последний, конечно, не произойдет (ну разве что какой-нибудь другой верстальщик приверженец веб-стандартов поругает), но ситуация похожая. Люди получили в свое распоряжение новый стандарт разметки страниц (которым их никто, конечно же, не заставляет пользоваться) и спецификацию к нему, которая описывает, что для каких целей применять (с определенной долей свободы).
НЛО прилетело и опубликовало эту надпись здесь
Нет, я как раз про новые теги. Их назначение описывается в спецификации, которую верстальщики редко читают, руководствуясь при верстке только своими собственными соображениями о назначении элементов.
Плохие верстальщики значит, если спек не читают…
Сегодня в мире принято считать, что рулит демократия, так что если 90% профессиональных верстальщиков нарушают спецификации — значит это плохие, негодные спецификации, и нужно просто выкинуть теоретиков из комитета w3c.
Так и есть :) В w3c, по-моему, реальный мир не видели уже лет 10, точно :)
Ну, знаете, если кто-то предлагает мне как программисту воспользоваться библиотекой ну там классов или как здесь — элементов, причем это библиотека для примитивных таких вещей, отнюдь не для решения уравнений Навье-Стокса в криволинейных частных производных — и этот кто-то говорит, что мне нужно внимательно прочесть и освоить 500-страничную документацию, чтобы что-то там у кого-то другого работало корректно — ну знаете, я скажу что это плохая, негодная библиотека с плохим, негодным дизайном. И 99% программистов меня поддержат. Потому что если мне, профессионалу, не очевидны даже базовые, элементарные вещи — ну, это вообще ни в какие рамки не лезет.
Если ваша библиотека классов была обновлена (HTML4 -> HTML5), то перед использованием новых классов (элементов) программист (верстальщик) поинтересуется что они из себя представляют и для чего нужны.
Стандарт еще не утвержден и как раз сейчас самое время его критиковать. Размытость и невнятность некоторых новых семантических элементов это слабое место HTML5 над которым имеет смысл поработать.

К примеру, из вашей же статьи очевидно, что header нелогичен и может быть правильно использован только после детальной инструкции, что практически гарантирует, что использован он будет неверно чуть более чем всеми. С ходу не ясно имеется ли ввиду header страницы, статьи или секции.
header может быть и у статьи, и у страницы, и у секции. а после статьи понятно, что использовать его надо только тогда, когда нужно подчеркнуть структурно кусок кода. ИМХО здесь мало чего нелогичного.
Профессор X изобрёл чудо-штуку, приложил к ней инструкцию и раздал бесплатно всем людям. Люди поленились прочитать инструкцию и начали вовсю пользоваться этой чудо-штукой, что привело к печальным последствиям. Кто виноват?
Отчасти виноваты другие Люди X, которые не сказали ему вовремя: «Ты слишком идеалистичен, Чарльз».
Дело в том, что огромное кол-во верстальщиков — безрукие идиоты, место которым за стойке в Макдональдсе, а не сайты верстать.
НЛО прилетело и опубликовало эту надпись здесь
> Если ошибки уж очень распространённые, то, может, дело не в тех, кто эти ошибки совершает, а в замысловатости спецификации?

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

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

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

Выше была приведена ссылка на статью о document outline, там в конце есть ссылки на outliner'ы. С их помощью Вы можете посмотреть на схему своего документа и оценить, насколько точно она передает его структуру.
Вадим pepelsbey Макеев более как-то красивее, качественнее и раньше перевёл и опубликовал данную статью.
Да, увы, я заметил её только после публикации этой статьи (RSS фид обновился только спустя несколько часов).
Если хабрасообщество решит, что эта статья не нужна, я, так и быть, уберу ее в черновики.
Оставляйте. Мне пригодилась.
<input type="email" name="email" required />
Тут либо лишний '/', либо на required парсер должен споткнуться. Неясно зачем смешивать синтаксисы HTML и более строгого XML. Надеюсь автор просто ошибся.
Ребят, я все понимаю! Но правда достало, на кой черт, этот ваш XML и XHTML нужен?
Я веду курсы по HTML вот уже 3 года.До этого долгое время работал в компании которая одной из первых представила комерческую CMS/DocFlow систему на CeBIT. И я правда не понимаю!

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

На мой взгляд XHTML это бастрад «странного стандарта — XML» и W3C, который, слава богу, явно, заканчивает свою карьеру.
для порядка он нужен.
Не нужен он для порядка.
XHTML еще очень долго проживет. Потому как он сейчас работает, везде где это нужно.
А вот HTML5 еще пилить и пилить, а потом изучать и изучать.
Начинай изучать сейчас, чтобы не изучать потом и больше. :)
Для обеспечения единства синтаксиса с другими языками разметки — SVG, XSLT, XSD, XUL, XBL, MathML, RSS… Их можно легко и ясно преобразовывать друг в друга, буде возникнет нужда. А неэксэмэльконформный HTML — не пойми что и сбоку бантик.
И что? Кому надо что-то преобразовать — возьмет и напишет нормальный парсер. Почему из-за него должен страдать миллион верстальщиков?
Пусть не страдают; чтобы придерживаться XML-синтаксиса, это не обязательно.
Меня как программиста выбешивает необходимость заключать в кавычки числа, идентификаторы и члены перечислений. Есть синтаксис, принятый в подавляющем большинстве языков программирования, включая Javascript, PHP, CSS, нормальном HTML и т.п. и т.д., которые в реальных CMS идут сплошным комком. Запись вида
<img id=img1 width=42 align=right alt=«Картинко»>
— синтаксически нормальна. Но этот же элемент в стиле XHTML (с кавычками) вызывает почти физическое неприятие, руки сами тянутся убрать лишние символы. И главное, ради чего? Потому что кто-то там настолько криворук, что не может распарсить числа без кавычек?
Неиспользование кавычек может вам самим проблемы доставить. Себе жизнь усложните.
o rly? например как?
Ни в Javascript, ни в PHP такое — «id=img1» — не прокатит. А width и тем более align — это презентационные особенности, им в HTML вообще не место. Если Вам угодно писать архаичный HTML, тогда не удивительно, что Вам для этого хочется использовать архаичный синтаксис.

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


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

Между прочим, в PHP нет удовлетворительного по возможностям встроенного парсера HTML, а сторонний PHP Simple HTML DOM Parser занимает 53 килобайта (и на практике всё равно не со всякой страницей справляется).
У как всё запущено. Вы сначала разберитесь, зачем нужны width и align в img:)
По остальному тоже смешно, если очередной школьник, тырящий контент для своего говносайта под сапу настолько туп, что не может найти в интернете нормальный парсер html — это исключительно его трудности, но никак не верстальщков сайта-жертвы:)
Я, как бы, уже семнадцать лет не школьник. Возможно поэтому я не пишу картинке выравнивание в атрибуте; если мне нужен поплавок, я делаю его надлежащим образом — через стили. А Вы так и пишете align? Окститесь, XXI век давно наступил.
Я не знаю что и как вы там делаете, но вы явно далеки от продакшена.
Понимаете, в оформлении сайтов тэг img практически не используется, ну разве что кроме логотипа. Всё оформление идёт через background-image, да, вот там стили, классы и прочая прочая, чтобы повторяющиеся элементы оформления были описаны один раз.
Тэг img — это тег содержания, которое на каждой важной странице сайта уникально. Вставить картинки в статью или там вывесить фотки товара — вот его основное использование. И вот тут никаких классов быть не может, потому что в каждой статье свои уникальные картинки, и где им нужно быть — слева, справа или там по центру — решает девочка — контент-менеджер. Которая скорее всего какой-нибудь там филолог, она правильно расставляет запятые с жесткими переносами и знает языков эдак 5 — но названия всех из них заканчиваются на "-ий". И в своей работе она использует какой-нибудь там TinyMCE (хотя и не знает такого слова), потому что его прикрутили в админку, потому что он похож на Word и даже девочки-филологи способны его освоить. Ну а то что генерируемый им код не блещет чистотой — так зато работает как надо.
(Кстати, сейчас проверил: свежий TinyMCE вместо align=right наконец-то стал использовать более современный style=«float: right», так что я можно сказать зря на него грешил).
Стремление просвещать народ, как делаются сайты, похвально, но мне неясно как отсюда следует необходимость для программиста прописывать презентационные атрибуты.

И: если расположение каждой картинки (и говоря шире — элементов содержания вообще) на каждой странице уникально и никаким закономерностям не подчиняется, то это дрянная, беспорядочная, безвкусная вёрстка — вот что я скажу.
…И вообще программисту по-хорошему незачем расставлять все эти кавычечки и даже думать о них (или об их отсутствии, что, по-моему, заморочней). Это устаревшая методика — писать HTML-код прямо из скрипта. Шаблонизаторы и фреймворки должны этим заниматься. А они будут друг друга замечательно понимать, если в них закладывать XML-синтаксис.
Если закладывать XML-синтаксис между фреймворком и шаблонизатором, то они будут замечательно тормозить. И вообще подобные архитектурные решения обычно указывают на серьезные заболевания головного мозга придумавшего это программиста.
И да, веб-программисту необходимо прекрасно знать html+css и даже приходится периодически самому верстать некие блоки html-кода. И никакой волшебный шаблонизатор за него это не сделает.
Между фреймворком и шаблонизатором — обычно незачем. А вот на выходе его иметь будет очень любезно — перед сторонними фреймворками и шаблонизаторами, которые вздумают с этим работать.
встречаем тэг svg, переключаемся в строгий svg-парсер. видим закрывающий тэг svg, переключаемся в нестрогий html-парсер. В чем проблема-то? ;)
Чего ради мешать в одном документе разные синтаксисы? С точки зрения XML разница между этими языками только в пространстве имён — и это замечательно: можно применять одни методы и преобразовывать одно в другое посредством XSLT. XML великолепен своим универсализмом, так зачем раздирать это единство?
«12 причин», видимо, писались как пародия. Особенно доставило в качестве недостатка XHTML: «HTML гораздо сложнее парсить (автоматически копировать) чем XHTML, который как раз и предназначен для облегчения парсинга».
А в чем проблема? Парсер видит атрибут /, не знает, что это такое и с чистой совестью игнорирует.
Тогда это мусор. Некоторые — и я в их числе — полагают, что мусор в полезном содержимом заведомо являет собой проблему.
Это дополнительная информация о том, что тег закрыт тут же. Один символ позволяет человеку легко осознавать, что у текущего тега нету закрывающего даже без прочтения названия
Подсказки человеку — это дело для IDE. А для машины этот слэш — мусор.

Да и у человека он вызывает переклин, ложно побуждая считать код XML-ем.
В таком случае и символы перевода каретки и новой строки для машины — мусор.
Свои сайты вы пишете в одну строку?
Некоторые фрагменты приходится. Смотрите мой коммент ниже.

Да, было бы неплохо писать весь сайт в одну строку, если бы IDE сами раскладывали его дерево.
Многие IDE умеют редактировать XML в виде дерева — на выходе всё будет в одну строку.
А посоветуйте.
Altova XMl Spy, если не ошибаюсь
Платный же. Идея потратить 400—800 евро меня как-то мало возбуждает.
Eclipse?
Отступы и пробелы тоже мусор.
И это проблема. Например, внутри инлайнового элемента. Неужто Вам не приходилось писать теги в одну строчку подряд, чтобы избежать появления промежутков между блоками? Выглядит это безобразно, а что делать? Писать ради оформления кода font-size: 0? Если бы ещё все браузеры это нормально понимали.
white-space:nowrap (если забить на седьмой ие)
И что? Попробуйте:

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


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

Согласно html5 незакрытые теги можно закрывать таким образом.
<script type="text/javascript" src="js/scripts" /></script>
<script src="js/scripts" /></script>
В оригинале этого не было. ;)
В оригинале было много ошибок — почитайте комментарии, просто их исправили.
Спасибо, исправил.
Пользователь BekoBou уже как бы указал на данную статью выше, зачем повторятся-то?
Пардон, не заметил.
думаю, чтобы люди научились пользоваться html5 нужно ужесточить валидацию
Валидацию семантики сложно производить, по-моему.
Да вроде не особенно. Зародыш подобного я видел некоторое время назад в SEO тулзах в панели управления GoDaddy. Оно там, например, умело разбирать что написано в тэгах <h?> и как это относится к собственно контенту.
Т.е. все упирается в анализ текста в семантических блоках (и структуру этих блоков) имхо.
>Избегаем распространенных HTML5 ошибок
Избегаем распространенные ошибки в HTML5

Fixed.
В HTML5 нет ошибок. По крайней мере, здесь обсуждаются не они.
«В разметке на языке HTML5», «за сайтами в галерее HTML5», «сайтов на HTML5» и пр. «HTML5 ошибок» — это калька с английского, а не перевод.
Спасибо, исправил.
НЛО прилетело и опубликовало эту надпись здесь







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

 <div role="main">
    <!-- Контент страницы -->
  </div>
  <aside role="complementary">
    <!-- Дополнительный контент -->
  </aside>
То есть если я правильно понял то прийдеться вешать на тот же чекбокс еще и role
<input type="checkbox" role="checkbox" />


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

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


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

нет. надо ввести новые теги, а потом сверху к этому еще докручивать rdf, goodrelations и толпу еще непонятно чего
Мне кажется вообще все перегрузили. Множество элементов теперь друг друга дублируют разными способами.
Статья говорит не делайте так, но не везде объясняет почему. Например, про и
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории