27 июля 2011 в 23:17

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

HTML*
HTML5 Уважаемые хабровчане, представляю вам вольный перевод статьи Avoiding common HTML5 mistakes. Здесь мы рассмотрим частые ошибки в HTML5 разметке с точки зрения семантики, и как их избежать.

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

Не используйте тег <section> в качестве обёртки для оформления


Одна из наиболее общих проблем, замеченных мною, — банальная замена <div>'ов на структурные элементы HTML5, особенно на <section>'ы. Т.е. когда то, что в XHTML или HTML4 выглядит так:
<!-- Код в стиле HTML 4 -->
<div id="wrapper">
  <div id="header">  
    <h1>My super duper page</h1>
    <!-- Содержимое хедера -->
  </div>
  <div id="main">
    <!-- Контент страницы -->
  </div>
  <div id="secondary">
    <!-- Дополнительный контент -->
  </div>
  <div id="footer">
    <!-- Содержиме футера -->
  </div>
</div>
Переписывают так:
<!-- Не используйте этот код! Он неверен! -->
<section id="wrapper">
  <header>  
    <h1>My super duper page</h1>
    <!-- Содержимое хедера -->
  </header>
  <section id="main">
    <!-- Контент страницы -->
  </section>
  <section id="secondary">
    <!-- Дополнительный контент -->
  </section>
  <footer>
    <!-- Содержимое футера -->
  </footer>
</section>

Это просто неправильно: <section> не обёртка. Этот элемент означает семантический блок Вашего контента, использующийся для построения «структуры документа» (document outline), и должен содержать заголовок. Если Вам нужен элемент для обёртки, попробуйте обойтись <body> (Kroc Camen может предложить кое-что). Если это не решает проблему необходимости дополнительных обёрток, используйте старые добрые <div>'ы. С приходом HTML5 <div>'ы не умерли, и именно они отлично подходят в этом случае.

Принимая во внимание все вышесказанное, было бы хорошо разметить пример выше с использованием HTML5 так:
<body>
  <header>  
    <h1>My super duper page</h1>
    <!-- Содержимое хедера -->
  </header>
  <div role="main">
    <!-- Контент страницы -->
  </div>
  <aside role="complementary">
    <!-- Дополнительный контент -->
  </aside>
  <footer>
    <!-- Содержимое футера -->
  </footer>
</body>


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

Используйте <header> и <hgroup> только при необходимости


Нет смысла писать код, если в этом нет необходимости, правда? Увы, но я часто наблюдаю, как <header> и <hgroup> там, где они не нужны. Вы можете почитать об элементах <header> и <hgroup> подробнее, я же коротко обозначу ключевые моменты:
  • Элемент <header> представляет группу вводных или навигационных средств и обычно содержит заголовок секции
  • Элемент <hgroup> группирует набор элементов <h1>-<h6>, представляя заголовок секции в случае, если он состоит из нескольких уровней (подзаголовки, альтернативные заголовки и т.д.)


Избыток элементов <header>

Я уверен, Вы прекрасно знаете, что элемент <header> можно использовать несколько раз в документе. Поэтому часто встречается такое:
<!-- Не используйте этот код! Здесь header не нужен! -->
<article>
  <header>  
    <h1>My best blog post</h1>
  </header>
  <!-- Содержимое статьи -->
</article>


Если Ваш <header> содержит только один заголовочный элемент, то он не нужен. В данном случае элемент <article> уже гарантирует, что заголовок будет включен в «структуру документа» (document outline), и раз <header> не содержит нескольких элементов (согласно определению), его можно безопасно удалить. Достаточно просто этого:
<article>  
  <h1>My best blog post</h1>
  <!-- Содержимое статьи -->
</article>


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

И снова о заголовках: я часто вижу некорректное использование элемента <hgroup>. Не следует использовать <hgroup> вместе с <header>, если:
  • Присутствует только один заголовок
  • <hgroup> хорош сам по себе (т.е., без <header>).

Первый случай:
<!-- Не используйте этот код! Здесь hgroup не нужен -->
<header>
  <hgroup>  
    <h1>My best blog post</h1>
  </hgroup>
  <p>by Rich Clark</p>
</header>


В этом случае просто уберите hgroup.
<header>
  <h1>My best blog post</h1>
  <p>by Rich Clark</p>
</header>


Второй случай — это еще один пример использования элемента без необходимости.
<!-- Не используйте этот код! Здесь header не нужен -->
<header>
  <hgroup>  
    <h1>My company</h1>
    <h2>Established 1893</h2>
  </hgroup>
</header>


Если единственный ребёнок <header>'а это <hgroup>, зачем нужен <header>? Если у Вас нет дополнительных элементов в <header>'е (т.е. сестринских по отношению к <hgroup>), просто уберите <header>.
<hgroup>
  <h1>My company</h1>
  <h2>Established 1893</h2>
</hgroup>


Подробнее об элементе <hgroup> можно почитать тут.

Не обрамляйте все ссылки в <nav>


В HTML5 было введено 30 новых элементов, чтобы дать нам возможность создавать структурированную и осмысленную разметку. Но не следует злоупотреблять новыми семантическими элементами. К сожалению, это как раз то, что происходит с <nav>. Спецификация описывает <nav> так:

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

Примечание: Не все группы ссылок следует помещать в элемент nav. Его следует использовать для основной навигации. Часто в футерах размещают небольшой список ссылок на различные страницы сайта (Главная, Помощь, соглашение об использовании, etc). В этом случае одного footer'а должно быть достаточно. Хотя ничто не мешает использовать nav, в этом нет необходимости.
WHATWG HTML spec

Ключевая фраза — «основная навигация». Можно долго спорить о том, что понимать под основной, но для меня это:
  • Первичная навигация
  • Поиск по сайту
  • Вторичная навигация (спорно)
  • Внутристраничная навигация (внутри длинной статьи, например)

Хотя в этом случае сложно судить, что есть правильно, а что — нет, я считаю, что не стоит заключать в <nav>:
  • Переключатели страниц
  • Социальные ссылки (хотя возможны исключения в случаях, когда социальные ссылки являются основной навигацией. Например, сайты вроде about.me или flavours.me)
  • Теги поста
  • Категории поста
  • Третичная навигация
  • Объемные футеры

Если Вы не уверены, обрамлять ли список ссылок в <nav>, задайте себе вопрос: «Это основная навигация?». Примите во внимание следующее:
  • “Не используйте <nav>, если Вы считаете, что <section> с заголовком <hx> тоже подойдёт” — Hixie в IRC
  • Возможно стоит добавить «Перейти к» для удобства?

Если ответ на эти вопросы — «Нет», это, видимо, не место для <nav>.

Общие ошибки в использовании элемента <figure>


Ах, <figure>. Разобраться с правильным использованием этого элемента, как и его собрата <figcaption>, непросто. Давайте взглянем на некоторые общие ошибки, касающиеся этого элемента.

Не каждое изображение <figure>

Ранее, я советовал не писать больше кода, чем необходимо. Здесь похожая ситуация. Я встречал сайты, где каждая картинка была обрамлена в <figure>. Не нужно использовать больше разметки только для того, чтобы использовать больше разметки. Вы просто создаете себе больше работы, но никак не улучшаете описание своего контента.

Спецификация описывает <figure> как «автономный контент, возможно, с заголовком и обычно являющийся самостоятельным элементом потока». Вот она, вся красота <figure> — элемент можно спокойно переместить из основного содержимого, например, в сайдбар.

Вышеупомянутая блок-схема выбора элемента поможет Вам справиться с <figure>.

Если изображение несет только презентационную нагрузку, и на него нигде в документе не ссылаются, это определенно не <figure>. Иначе, задайте себе вопрос: «Необходимо ли это изображение в текущем контексте для понимания?». Если нет, это, видимо, не <figure> (возможно, <aside>). Если да, спросите себя, «Могу ли я переместить это в приложение?». Если ответ на оба вопроса Да, то, возможно, <figure> подойдёт.

Ваш логотип — не <figure>

Тоже самое касается и логотипа. Часто я вижу такое применение:
<!-- Не используйте этот код! Он неверен! -->
<header>
  <h1>
    <figure>
      <img src="/img/mylogo.png" alt="My company" class="hide" />
    </figure>
    My company name
  </h1>
</header>
<!-- Не используйте этот код! Он неверен! -->
<header>  
  <figure>
    <img src="/img/mylogo.png" alt="My company" />
  </figure>
</header>

Тут нечего добавить. Это просто неверно. Можно долго спорить о том, должен ли логотип быть в <h1>, но мы сейчас не об этом. Настоящая ошибка — злоупотребление элементом <figure>. <figure> следует использовать только когда Вы ссылаетесь на него в документе. Вряд ли Вы где-нибудь будете ссылаться на свой логотип. Достаточно этого:
<header>
  <h1>My company name</h1>
  <!-- Еще что-нибудь -->
</header>


<figure> может быть не только изображением

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

Не так давно я писал об элементе <figure> подробнее. Советую почитать, если Вы хотите разобраться получше или освежить воспоминания.

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


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

В HTML5 нет необходимости указывать атрибут type для элементов <script> и <style>. Хотя от них может быть непросто избавиться, если они автоматически добавляются Вашей CMS, нет смысла включать их в код, если Вы пишете его самостоятельно или можете управлять шаблонами. Т.к. все браузеры по-умолчанию считают, что все скрипты написаны на JavaScript, а стили — это CSS, такая разметка становится избыточной:
<!-- Не используйте этот код! Его разметка перегружена! -->
<link type="text/css" rel="stylesheet" href="css/styles.css" />
<script type="text/javascript" src="js/scripts"></script>

Вместо этого Вы можете просто написать:
<link rel="stylesheet" href="css/styles.css" />
<script src="js/scripts"></script>


Помимо прочего, Вы также можете сократить количество кода, расходующегося на указание кодировки. Глава Марка Пилгрима о семантике в книге Dive into HTML5 описывает все такие практики.

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


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

Логические атрибуты

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

Некоторые из новых атрибутов форм являются логическими, т.е. их наличие в разметке определяет поведение элементов. В том числе это:
  • autofocus
  • autocomplete
  • required


Я редко встречаю их, но в случае с required я видел такое:
<!-- Не используйте этот код! Он неверен! -->
<input type="email" name="email" required="true" />
<!-- Еще один плохой пример -->
<input type="email" name="email" required="1" />


В конечном счете, это ничем плохим не грозит. Клиентский HTML парсер встретит атрибут required в разметке и применит соответствующие правила. Но что если сделать по-другому и написать required=«false»?
<!-- Не используйте этот код! Он неверен! -->
<input type="email" name="email" required="false" />

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

Логическое значение возможно применить тремя способами: (Второе и третье характерны для XHTML)
  • required
  • required=""
  • required=«required=»


Применительно к нашему примеру выше, мы могли бы написать так (в HTML):
<input type="email" name="email" required />
Перевод: Richard Clark
B@rmaley.e⪥e @barmaley_exe
карма
96,5
рейтинг 0,1
Уверенный пользователь ПК
Похожие публикации
Самое читаемое Разработка

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

  • +3
    А не было бы более корректно заменить «Не каждое изображение фигура» на «Не каждое изображение иллюстрация». А «Ваш логотип — не фигура» на «Ваш логотип — не иллюстрация»
    • +5
      На мой взгляд, заменять фигуру на иллюстрацию не лучший шаг, т.к.
      В <figure> может быть заключено видео, аудио, графики (в SVG, например), цитата, таблица, блок кода, стихотворение или любая комбинация перечисленного.
      И если график или видео еще можно посчитать иллюстрацией, то вот аудиозапись или блок кода — вряд ли.
      • +2
        проиллюстрирую свою позицию следующей цитатой: «Иллюстрация (от лат. illustratio — освещение, наглядное изображение), 1) объяснение с помощью наглядных примеров.»
  • +24
    Я не большой специалист в HTML5, но мне кажется, если для выбора правильного элемента нужны такие обильные инструкции и диграммы, то что-то тут не так…
    • +7
      Это рекомендации по наполнению Вашей разметки смыслом. Цель всех этих шаманств — более подробно описать документ и его содержимое. В дальнейшем это может быть использовано поисковиками или специальными устройствами для людей с ограниченными способностями, например.
      Ваша разметка будет по-прежнему работать, даже если она составлена из одних дивов, но возможность извлечения дополнительной метаинформации будет сильно ограничена.
      • +13
        Я не о том.

        Если закон нарушают немногие, то проблема в этих немногих. Если закон нарушают почти все, то проблема в законе.

        Так и тут. Если ошибки уж очень распространённые, то, может, дело не в тех, кто эти ошибки совершает, а в замысловатости спецификации?
        • +1
          P.S. Заметьте, что уже с первого комментария начинаются разночтения.
        • +4
          Рассмотрим такой пример:
          Профессор X изобрел *чудо-штуку*, приложил к ней инструкцию и раздал бесплатно всем людям. Люди поленились прочитать инструкцию и начали во всю пользоваться этой чудо-штукой, что привело к печальным последствиям. Кто виноват?

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

      Согласно html5 незакрытые теги можно закрывать таким образом.
  • +2
    <script type="text/javascript" src="js/scripts" /></script>
    <script src="js/scripts" /></script>
    В оригинале этого не было. ;)
    • +1
      В оригинале было много ошибок — почитайте комментарии, просто их исправили.
    • +1
      Спасибо, исправил.
  • +1
    Ыыых, и эти люди, как говорится… Ссылка на flowchart: html5doctor.com/happy-1st-birthday-us/#flowchart (сама перематывает в тот самый низ поста).
  • +4
    Альтернативный перевод: web-standards.ru/articles/avoiding-html5-mistakes/
    • +1
      Пользователь BekoBou уже как бы указал на данную статью выше, зачем повторятся-то?
      • 0
        Пардон, не заметил.
  • 0
    думаю, чтобы люди научились пользоваться html5 нужно ужесточить валидацию
    • +5
      Валидацию семантики сложно производить, по-моему.
      • 0
        Да вроде не особенно. Зародыш подобного я видел некоторое время назад в SEO тулзах в панели управления GoDaddy. Оно там, например, умело разбирать что написано в тэгах <h?> и как это относится к собственно контенту.
        Т.е. все упирается в анализ текста в семантических блоках (и структуру этих блоков) имхо.
  • –1
    >Избегаем распространенных HTML5 ошибок
    Избегаем распространенные ошибки в HTML5

    Fixed.
    • 0
      В HTML5 нет ошибок. По крайней мере, здесь обсуждаются не они.
      • 0
        «В разметке на языке HTML5», «за сайтами в галерее HTML5», «сайтов на HTML5» и пр. «HTML5 ошибок» — это калька с английского, а не перевод.
        • 0
          Спасибо, исправил.
  • +3
    Читал раньше материалы по HTML5, и всё казалось логичным. Статьи, заголовки, навигация. После прочтения этого материала я понял, что ничего не понял ни тогда, ни сейчас :) «Как–то сложно всё, детка.»
  • +2







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

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


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

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


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

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

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