Чому б хотілося маркувати правильно та семантично маркування?

_{Зауважте, що я (намагаюся) позначати якомога більше семантично, тому що мені подобається, як вони це виглядають і відчувають, але не тому, що я знаю про будь-які інші приголомшливі переваги. Суть мого питання - вміти навчати інших}

Ну, я бачив багато статей та навчальних посібників, які часто зазначають "Давайте позначимо це найбільш смисловим способом".

Але дивна думка прийшла до мене, чому?

Чому потрібно (або хотіти) турбуватися про конкретні елементи, які передають правильний смисловий сенс? В Зокрема, я маю в виду нові елементи HTML5, наприклад <time>, <output>або <address>. Особливо, якщо сторінка "працює" (вона добре відображається у всіх браузерах).

Чому я хотів би використовувати такі елементи, як, <time>або <address>де взагалі нічого (або в гіршому випадку загальне <span>) не працює так само добре?

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

Вільна функціональність

Правильно за допомогою <label>s означає, що ви можете натиснути мітку, щоб ввести текстове поле. Багато браузери додадуть логічну функціональність за замовчуванням до багатьох тегів за офіційною специфікацією, це означає, що ви можете використовувати менше плагінів JavaScript і писати менше коду, ніж веб-сайт, створений повністю з <div>s та <span>s.

Доступність

Що стосується вільної функціональності, семантика дуже багато означає програмне забезпечення для читання екрана. Текст перед полем для введення не буде читатись так само, як <label>заповіт. Зчитувачі екрану ігноруватимуть більшість ваших CSS, тому це в основному залежить від структури вашого HTML.

Логічний CSS

Навіщо використовувати a, div #headerколи ви можете використовувати a <header>і стиль, що безпосередньо? Семантичні теги полегшують розмітку і роблять ваш стиль набагато портативнішим; якщо у вас є певний стиль для закреслення і завжди використовуєте <del>елементи, стиль набагато портативніший. <del>означає те ж саме для всіх, але кожен буде називати свій .deletedTextклас по-різному.

Це також допомагає утримати всіх на одній сторінці у великих проектах; нікому не подобається вивчати конвенції про іменування інших езотеричних класів.

SEO

Такі пошукові системи, як Google, розширили використання семантичних HTML та метаданих . Rich Snippets від Google також використовують спеціальні метадані, призначені для передачі смислового вмісту.

Чому це не все так часто

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

Нетехнологічним людям дуже важко зрозуміти або оцінити семантику HTML.

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

Якщо ви хочете, щоб семантичний HTML був пріоритетним для вашого проекту, вам потрібно подати справу для цього. Показ вашої команди / шефа, як працює ваш веб-сайт у читальному екрані, також є корисним інструментом.

Відповідь на це - просто передати інформацію та структурувати ваш документ .

Коли ви використовуєте прольоти та знаки, документ не має структури. Немає списків, немає абзаців, таблиць, гіперпосилань. Нічого. Немає сенсу вибирати HTML як мову розмітки, а потім ігнорувати словниковий запас, який він пропонує, щоб висловити та структурувати ваш вміст. Структура - тут важливе слово btw. HTML призначений для структуризації не відображення. Ось для чого і CSS.

Якщо ви розмічаєте свій код семантично, ви даєте людським читачам, а також машинам можливість зрозуміти дані всередині своїх елементів. Якщо ви використовуватимете елементи span та div повністю, ви не матимете такої додаткової інформації, і вивести їх із самих значень може бути неможливо.

Так само, якщо я хочу обрізати веб-сайти і лише витягнути заголовки, щоб створити для них зміст, моєму павукові потрібно буде знати, що таке заголовок. Це не може зробити без відповідних елементів.

І останнє, але не менш важливе значення, якщо ви використовуєте лише divs і spans, вам буде важко стилювати їх за допомогою CSS. CSS-селектори працюють над структурою вашого документа, і якщо це здебільшого неоднозначна структура, правила CSS можуть застосовуватися не просто. Як ви вирішите, чи div div divстосується насправді table tr tdчи body ul li? Тоді вам доведеться додати класи та ідентифікатори, але потім ви винаходите колесо.

Також дивіться рекомендації W3C

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

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

Однією з причин того, що ви не бачите багато сайтів, які ідеально слідують семантиці, - це те, що для цього не існує ділової справи багато часу. Якщо це стимулює продажі (або пов'язані з ними категорії, наприклад, експозиція), тоді варто написати свої гроші, щоб написати семантичний HTML.

Найкращий випадок, який я можу зробити для семантичного використання тегів, - це коли ви споживаєте або використовуєте HTML з інструментом. Наприклад, використання семантичних тегів дозволяє безпосередньо стильові елементи, не боячись додавати чи видаляти стилі з чогось іншого. Крім того, якщо вам коли-небудь доведеться проаналізувати HTML за допомогою скребка або чогось подібного, то ви неодмінно оціните добре сформований і семантичний HTML, оскільки стає легше писати запити XPath та DOM, щоб знайти те, що вам потрібно.

Слід зазначити, що класи не є прямою заміною семантичних тегів. У мене є класи для багаторазового використання, [error, information, warning]які передають різні значення, а тому стилі на основі тегу, до якого вони прикріплені.

Тому що це може бути корисно або потрібно для сканерів та веб-служб (комп'ютери AKA, що спілкуються з комп'ютерами). Якщо ви пишете:

<span class="time">Sep 16 at 2:17</span>

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

Якщо ви використовуєте:

 <time datetime="2012-02-11 16:24:02">feb 11 2012 at 16:24:02</time>

... будь-якому сканеру буде набагато легше знайти та проаналізувати матеріал.

Коли я кажу сканери, я не маю на увазі пошукові системи обов'язково :)

Я керую невеликою веб-консалтинговою компанією, і наш сучасний підхід полягає в тому, щоб не використовувати нові теги HTML5, оскільки ми намагаємось збалансувати багато факторів. У цьому випадку баланс між зручністю, зручністю використання та SEO:

• SEO: Що тут говорили інші відповіді - це може трохи допомогти SEO, хоча, виходячи з мого досвіду, чим очевидніша SEO стратегія, тим менше шансів допомогти.

• Корисність №1: розумно вважати, що теги HTML5 надають певну перевагу зручності використання. Для сліпих користувачів, безумовно, що все, що їх резервний браузер надає, стане кращим за все, що я можу надати. Для вашого типового користувача це набагато дискусійніше. Можливо, використання невідомого медіаплеєра, який надає ваш веб-переглядач, простіше у використанні, ніж менш знайомий віджет, який я б інакше помістив. А може, за замовчуванням у вашому браузері є лайно (як, наприклад, MP3-плеєр Chrome Windows за замовчуванням просто періодично перестає працювати).

• Використання №2: Старий IE. Старий IE вимагає купки HTML5 пробілів, які роздувають сторінку для того, щоб будь-який з цих тегів працював. Ви повинні додати деякий сценарій до тегів заголовка, який викликає CreateElement () у циклі для всіх тегів HTML5, які ви використовуєте. Якщо ви не збираєтесь розбирати кожну сторінку для тегів, якими ви користуєтесь, це означає кожен тег HTML5. Це потрібно виконувати на кожній окремій сторінці, вбудованій, тобто немає кешування. І погана новина: старий IE є найповільнішим у виконанні Javascript, тому він створює приємний маленький прихисток, поки він завантажується. Тоді вам доведеться заграти в купі старих JaE-файлів і CSS, що належать лише до IE, а часто і Flash, щоб усі нові непідтримувані елементи візуалізували правильно. Ви можете виявити функції, перш ніж вирішити завантажити старий код IE, але тоді ви змушує старих користувачів IE чекати, поки завантажиться достатня кількість скриптів, щоб зробити цю функцію, перш ніж навіть почати запитувати всі речі, які змушують ці теги працювати. Ви можете переглядати і лише надсилати старі речі IE користувачам із цими браузерами, але це може зробити кешування жорстким або неможливим залежно від вашої платформи. Надання різних кодів різним користувачам також означає тестування складніше - коли-небудь помилка асинхронії? Як щодо того, що трапляється лише у певному браузері? І тільки у виробництві? Підпишіться на мене. Отже, ви, мабуть, просто збираєтесь надіслати цей розмах всім. Надання різних кодів різним користувачам також означає тестування складніше - коли-небудь помилка асинхронії? Як щодо того, що трапляється лише у певному браузері? І тільки у виробництві? Підпишіться на мене. Отже, ви, мабуть, просто збираєтесь надіслати цей розмах всім. Надання різних кодів різним користувачам також означає тестування складніше - коли-небудь помилка асинхронії? Як щодо того, що трапляється лише у певному браузері? І тільки у виробництві? Підпишіться на мене. Отже, ви, мабуть, просто збираєтесь надіслати цей розмах всім.

Поки IE8 не помре, значення цих нових тегів HTML5 просто недостатньо високе для проблем із ефективністю, які вони приносять. Ми ще працюємо з аудиторією, де це навіть близько до мертвого *, але колись.

* Наші останні показники показують IE8 на рівні 6% для сайту з найменшим числом відвідувачів IE8 і 24% для самих відвідувачів IE8. Далеко, далеко від мертвих.

Коротка відповідь - «Немає вагомих причин на практиці». Майже всі аргументи, висловлені на користь «семантичної» розмітки, - це лише думка про те, що може чи має статися, а не щось відчутне. Наприклад, часто звертаються до пошукових систем, але немає жодних публічних доказів того, що вони піклуються про timeабо outputабо address.

Очевидно, ми можемо зробити висновок, що вони не хвилюються в осяжному майбутньому. Сайт schema.org деякими провідними пошуковими системами явно віддає перевагу специфічному підходу до «семантичної розмітки», заснованому на чомусь зовсім іншому, а саме мікроданих ( itemscopeта пов'язаних з ними атрибутах). І вони насправді роблять це в основному для великих комерційних або громадських сайтів.

Використання spanабо divпрацює більш красиво, ніж новинки HTML5, оскільки останні не розпізнаються старими версіями IE навіть для цілей стилізації. Тому вам потрібна хитрість, щоб вони працювали навіть як контейнерні елементи.

Однак є деякі "смислові" елементи, які мають реальне значення, яке їм призначають браузери, допоміжне програмне забезпечення або пошукові системи. Використання h1для основного заголовка завжди було хорошою практикою з таких причин. Використання labelдля міток поля форм має реальний вплив на зручність використання та доступність. І так далі; див . прагматичний посібник з HTML: Принципи .

HTML - це не лише мова інтерфейсу, але й мова структурування даних. Він був розроблений, щоб допомогти неоднорідним машинам мати один загальний спосіб ідентифікації типу інформації, що надходить на сервер. Звідси стільки різних тегів. Сторінки HTML слід розглядати як структури даних.