Shares

Це вільний переклад статті Avoiding common HTML5 mistakes. Тут ми розглянемо часті помилки в HTML5 розмітці з точки зору семантики, і як їх уникнути.

Спостерігаючи за сайтами в HTML5 галереї і відповідаючи на запитання користувачів, я бачив безліч сайтів HTML5 і їх розмітку. У цій статті я покажу деякі помилки і погані практики розмітки, які я часто зустрічав, і поясню, як уникнути їх.

1. Не використовуйте тег як обгортки для оформлення

Одна з найбільш загальних проблем, помічених мною, — банальна заміна
‘ів на структурні елементи HTML5, особливо на ‘и. Тобто коли те, що в XHTML або HTML4 виглядає так:

My super duper page

Переписують так:

My super duper page

Це просто неправильно: не обгортка. Цей елемент означає семантичний блок Вашого контенту, що використовується для побудови «структури документа (document outline), і повинен містити заголовок. Якщо Вам потрібний елемент для обгортки, спробуйте обійтися (Kroc Camen може запропонувати дещо). Якщо це не вирішує проблему необхідності додаткових обгорток, використовуйте добрі старі
‘и. З приходом HTML5
‘и не померли, і саме вони відмінно підходять в цьому випадку.

Беручи до уваги все вищесказане, було б добре розмітити приклад вище з використанням HTML5 так:

My super duper page

Якщо Ви не впевнені, який елемент використовувати, то я раджу Вам скористатися нашою блок-схемою вибору елемента (прим. перекладача: див. в самому низу запису).

2. Використовуйте тільки при необхідності

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

  • Елемент представляє групу вступних або навігаційних засобів і зазвичай містить заголовок секції
  • Елемент групує набір елементів

    , представляючи заголовок секції у разі, якщо він складається з декількох рівнів (підзаголовки, альтернативні заголовки і т. д.)

Надлишок елементів
Я впевнений, Ви прекрасно знаєте, що елемент можна використовувати кілька разів в документі. Тому часто зустрічається таке:

My best blog post

Якщо Ваш містить тільки один заголовковий елемент, то він не потрібен. В даному випадку елемент вже гарантує, що заголовок буде включений в «структуру документа (document outline), і раз не містить декілька елементів (за визначенням), його можна видалити. Достатньо просто цього:

My best blog post

Неправильне використання

І знову про заголовках: я часто бачу некоректне використання елемента . Не слід використовувати , якщо:

  • Є тільки один заголовок
  • хороший сам по собі (тобто, без ).

Перший випадок:

My best blog post

by Rich Clark

У цьому випадку просто приберіть hgroup.

My best blog post

by Rich Clark

Другий випадок — це ще один приклад використання елемента без необхідності.

My company

Established 1893

Якщо єдина дитина ‘а це , навіщо потрібен ? Якщо у Вас немає додаткових елементів в ‘е (тобто сестринських по відношенню до ), просто приберіть .

My company

Established 1893

Детальніше про елементі можна почитати тут.

3. Не обрамляйте всі посилання

В HTML5 було введено 30 нових елементів, щоб дати нам можливість створювати структуровану і осмислену розмітку. Але не слід зловживати новими семантичними елементами. На жаль, це як раз те, що відбувається . Специфікація описує так:

Елемент nav являє секцію сторінки, що пов’язує її з іншими сторінками або частинами поточної (секцію з навігаційними посиланнями).

Примітка: Не всі групи посилань слід поміщати в елемент nav. Його слід використовувати для основної навігації. Часто в футерах розміщують невеликий список посилань на різні сторінки сайту (Головна, Допомога, угоду про використання, etc). У цьому випадку одного footer’а повинно бути достатньо. Хоча ніщо не заважає використовувати nav, в цьому немає необхідності.

Ключова фраза — «основна навігація». Можна довго сперечатися про те, що розуміти під основною, але для мене це:

  • Первинна навігація
  • Пошук по сайту
  • Вторинна навігація (спірно)
  • Внутристраничная навігація (всередині довгій статті, наприклад)

Хоча тут важко судити, що є правильно, а що — ні, я вважаю, що не варто укладати в :

  • Перемикачі сторінок
  • Соціальні посилання (хоча можливі виключення у випадках, коли соціальні посилання є основною навігацією. Наприклад, сайти на кшталт about.me або flavours.me)
  • Теги поста
  • Категорії посади
  • Третинна навігація
  • Об’ємні футеры

Якщо Ви не впевнені, обрамляти список посилань , задайте собі питання: «Це основна навігація?». Візьміть до уваги наступне:

  • “Не використовуйте , якщо Ви вважаєте, що з заголовком теж підійде” — Hixie в IRC
  • Можливо варто додати «Перейти до» для зручності?

Якщо відповідь на ці питання — «Ні», це, мабуть, не місце .

4. Загальні помилки у використанні елемента

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

Не кожне зображення

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

Специфікація описує як «певний автономний контент, можливо, з заголовком і зазвичай є самостоятельым елементом потоку». Ось вона, вся краса — елемент можна спокійно перемістити з основного вмісту в сайдбар, наприклад.

Вищезгадана блок-схема вибору елемента допоможе Вам впоратися з .

Якщо зображення несе тільки презентаційну навантаження і на нього ніде в документі не посилаються, це безперечно . Інакше, для початку запитайте себе, «чи Необхідно це зображення для розуміння в поточному контексті?». Якщо ні, це, мабуть, не (можливо ). Якщо так, запитайте себе: «чи Можу я перемістити це додаток?». Якщо відповідь на обидва питання “Так”, то, можливо, підійде.

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

Теж саме стосується і логотипу. Досить часто я бачу таке застосування:


My company name


Тут нічого додати. Це просто неправильно. Можна довго сперечатися про те, чи має логотип бути в

але ми зараз не про це. Справжня помилка — зловживання елементом . слід використовувати тільки коли Ви посилаєтеся на нього в документі. Я думаю, навряд чи Ви будете посилатися на свій логотип де-небудь. Досить цього:

My company name

може бути не тільки зображенням

Інший частий випадок непорозуміння елемента полягає в припущенні, що його можна застосовувати тільки для картинок. Але це не так. Може бути укладено відео, аудіо, графіки (SVG, наприклад), цитата, таблиця, блок коду, вірш або будь-яка комбінація перерахованого. Не обмежуйте себе у використанні одними картинками. Наше завдання як прихильників веб-стандартів — описати контент нашої розмітки.

Не так давно я писав про елементі докладніше. Раджу почитати, якщо Ви хочете розібратися краще або освіжити спогади.

[adsense]

5. Не використовуйте непотрібний атрибут type

Це, можливо, найбільш загальна проблема, що зустрічається в HTML5 галереї. Хоча це і не помилка, я вважаю, що краще уникати цього.

В HTML5 немає необхідності вказувати атрибут type для елементів та . Хоча від них може бути непросто позбутися, якщо вони автоматично додаються Вашої CMS, немає сенсу включати їх в код, якщо Ви пишете його самостійно або можете управляти шаблонами. Оскільки всі браузери за замовчуванням вважають, що всі скрипти написані на JavaScript, а стилі CSS, така розмітка стає надлишковою:

Замість цього Ви можете просто написати:

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

6. Некоректне використання атрибутів форм

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

Логічні атрибути
Логічні атрибути також існують для мультимедіа елементів і деяких інших. Правила, описувані мною, застосовні і для них.

Деякі з нових атрибутів форм є логічними, тобто їх наявність у розмітці визначає поведінку. В тому числі це:

  • autofocus
  • autocomplete
  • required

Я рідко зустрічаю їх, але у випадку з required я бачив таке:


У кінцевому рахунку, це не загрожує нічим поганим. Клієнтський HTML парсер зустріне атрибут required в розмітці і застосує відповідні правила. Але що якщо зробити по-іншому і написати required=«false»?

Парсер як і раніше бачить атрибут required і застосує відповідну поведінку, незважаючи на те, що Ви вказали йому не робити цього. Очевидно, це не те, чого Ви хотіли.

Є 3 способи застосувати логічне значення. (Друге і третє характерні для XHTML)

  • required
  • required=»»
  • required=«required=»

Стосовно нашого прикладу Вище, ми могли б написати так (HTML):

взято з http://habrahabr.ru/

Схоже

Share on Facebook Share
0
Share on TwitterTweet
0
Share on Google Plus Share
Share on Pinterest Share
0
Share on LinkedIn Share
Share on Digg Share
0
Total Shares
comments powered by HyperComments!