Семантика в HTML 5

Поки в HTML 5 є дві проблеми: відсутність зворотної сумісності, так як нові семантичні елементи не будуть працювати в 75 відсотках браузерів, і відсутність сумісності з майбутніми версіями, оскільки семантичні елементи не є розширюваними. Якщо винахід нових елементів – не вихід, то що ж робити?

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

Давайте зупинимося і подумаємо про нашу відповідальність. Волею випадку ми пов’язані з розробкою важливого засобу комунікації, який наша цивілізація буде використовувати протягом десятиліть. Тому коли ми, цілеспрямовано або мимоволі, замислюємося про поліпшення HTML, ми повинні розуміти, наскільки серйозні наслідки можуть мати рішення, зроблені сьогодні.

HTML 5, який з подвійною силою розробляється W3C в якості наступного покоління HTML, за останній рік отримав значний імпульс у розвитку. Це величезний проект, який стосується не тільки структури HTML, але також і моделей парсингу, обробки помилок, DOM, алгоритмів вибірки ресурсів, медіа-контенту, 2D-малювання, створення шаблонів для даних, моделей безпеки, завантаження сторінок, зберігання даних на стороні клієнта і так далі.

Це також і перегляд структури, синтаксису і семантики HTML, про що частково розповів Лакло Хант (Lachlan Hunt) в своєму «Огляді HTML 5».

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

BBC недавно повідомила про припинення використання формату hCalendar в списку передач через проблеми з загальнодоступністю і юзабіліті при використанні шаблону проектування abbr. Це, безумовно, свідчить про те, що семантична складова HTML досягла межі своїх можливостей, справді, це досить часте явище серед мов. Нам просто не вистачає елементів і атрибутів для більш виразної розмітки семантики документів. Якщо ми продовжимо використовувати існуючі конструкції HTML, то зіткнемося з усіма перерахованими проблемами. Але у HTML, як у мови семантичної розмітки, є і більш фундаментальний недолік – його семантика фіксована і не здатна до розширення.

Це не просто теоретична проблема. Сотні тисяч веб-розробників використовують атрибути class і id для створення семантично більш виразноюї розмітки. (Вони також використовуються для опису в CSS-стилях, але це зовсім інший випадок.) У більшості випадків, ці веб-розробники використовують довільну термінологію, значення, які вони самі придумали, а не взяті з існуючих схем. У кращому випадку така розмітка є псевдосемантичною.

Багато веб-сторінок використовують мікроформати для поліпшення семантичної структури існуючого набору HTML-елементів і атрибутів. В цьому випадку, значення атрибута class встановлюються по заздалегідь визначеним схемам, іноді запозиченим з інших стандартів, наприклад vCard, або, якщо визнаних стандартів не існує, створюється власна термінологія (як у випадку з hReview).

Розширювана семантика

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

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

Крім того, рішення має бути сумісним з майбутніми версіями. Не в тому сенсі, що воно повинно працювати в майбутніх версіях браузерів – це обов’язок розробників браузерів – рішення повинно бути розширюваним. Ми не можемо сподіватися, що знайдене рішення впорається з усіма можливими завданнями в майбутньому. Але ми можемо розробити рішення, яке було б розширюваним і могло б задовольняти нові потреби надалі.

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

Отже, що ж нам пропонує HTML 5? У ньому вводиться кілька нових елементів. Деякі з них є «структурними»: section, nav, aside, header і footer. Елемент dialog – це змістовний елемент, схожий на blockquote. Також введені елементи даних, такі як meter, який «служить для представлення чисел в певному інтервалі або дрібних значень, наприклад, кількості вільного місця на диску», і time, який використовується для зазначення дати і/або часу.

Ці елементи можуть бути корисні і викликають певний інтерес, але чи здатні вони вирішити описану нами проблему, зокрема, обмеження на зворотну і майбутню сумісність?

Давайте розглянемо кожне з обмежень.

Зворотня сумістність

Як браузери обробляють нові елементи, наприклад section? Що ж, останні версії Safari, Opera, Mozilla і навіть IE7 згенерують сторінку правильно.

Заголовок першого рівня

Заголовок другого рівня

Текст в елементі section.

Заголовок третього рівня

Початок чудовий. Але якщо ми спробуємо застосувати стилі до елементу section:

section {color: red}

… більшість зі згаданих браузерів впораються з завданням, а ось IE7 (і, відповідно, 6) – ні.

Таким чином, ми маємо серйозні проблеми з сумісністю в 75% використовуваних в даний момент браузерів. Знаючи «період напіврозпаду» браузера Internet Explorer, можна припустити, що багато хто буде користуватися ним ще протягом декількох років.

Яка ймовірність, що переважна більшість розробників стануть використовувати ці нові елементи HTML 5, знаючи що вони несумісні з більшістю браузерів? (Примітка перекладача: не варто бути таким категоричним в оцінках, так як частка IE7 і IE6 не складає більшості, і, до того ж, зменшується з кожним місяцем.)

На жаль, якщо ви спробуєте вирішити проблему з CSS іншим способом, наприклад, привласненням елементу section атрибута class і використанням його в таблиці стилів, то знову зазнаєте невдачі в IE. Можливо, є якийсь вихід, але поки він не знайдений, це буде серйозною перешкодою.

Давайте розглянемо таке обмеження – майбутню сумісність.

Майбутня сумісність

Задамо собі таке питання: «Чому ми повинні вигадувати нові елементи?». Розумною відповіддю було б: «Тому що в HTML бідна семантика, а додаючи ці елементи ми робимо її різноманітнішою – непогано, чи не так?».

Додаючи ці елементи, ми задовольняємо свої потреби лише в обмежених масштабах. Неважливо, скільки елементів ми вже прикрутили, завжди буде хотітися зробити семантику ще більш різноманітною. Тому, додаючи стільки елементів, скільки буде потрібно, ми так і не вирішимо проблему. Не потрібно додавати нові терміни в словник HTML, треба створити механізм, який дозволить надавати документу якийсь семантичний контекст. Формально, нам потрібно зробити HTML розширюваним. А HTML 5 не пропонує ніяких механізмів розширення.

Замість цього, HTML 5 додає елементи, які зараз не працюють в багатьох браузерах і в дійсності не дозволяють нам розширити семантику мови.

Щодо нових елементів залишаються ще деякі питання. Звідки були взяті їх імена? Як було прийнято рішення про необхідність елемента навігації з ім’ям «nav»? Чому один і той же термін застосовується до навігації як всередині сторінки, так і по сайту, і навіть між сайтами?

Чому б не взяти існуючий словник термінів, наприклад Docbook? Його словник набагато більш різноманітний, і розроблявся фахівцями у видавничій діяльності протягом багатьох років. Це не аргумент на підтримку Docbook, суть в тому, що надзвичайно важливе завдання створення семантичних механізмів в HTML вирішується такими непродуманими методами, майже не зважаючи на накопичений за останні 30 років досвід розробок в цій галузі. (Розробка GML почалася в 1970-х роках.)

Думки з приводу рішення

Після всієї критики, чи можу я запропонувати якесь практичне вирішення цієї проблеми? Дійсно, у мене є деякі міркування.

Якщо додавання нових елементів не допоможе справі, принаймні, в рамках нашої дискусії, варто звернути увагу на атрибути HTML. Зрештою, ми вже років десять використовуємо class і id для розширення семантики HTML. Безліч розробників знайомі з такою практикою і повністю нею задоволені. Проект microformats показав, що існуючих атрибутів HTML в загальному недостатньо для розширення семантики. Тому, якщо ми хочемо вирішити проблему за допомогою атрибутів, доведеться використовувати один або кілька нових атрибутів. Перед тим як зрозуміти, як це може працювати, варто подумати про вже згадані обмеження. Головне – чи будуть нові атрибути зворотньо сумісні? І якщо так, то чи можуть вони запропонувати робочий механізм для розширення семантики HTML?

Давайте придумаємо новий атрибут. Я назву його «structure», хоча ім’я не має значеня. Ми можемо використовувати таку конструкцію:

Подивимося, як з цим впораються браузери.

Звичайно, у всіх браузерах до цього елементу можна застосувати стилі:

div {color: red}

Але як щодо такого?

div[structure] {font-weight: bold}>

Насправді, майже всі браузери, включаючи IE7, дозволяють це зробити, навіть якщо атрибута structure немає в HTML! На жаль, потім нам не везе- IE6 так не вміє. Проте, ми можемо використовувати цей атрибут – всі існуючі браузери його розпізнають, а всі сучасні браузери дозволять додавати для нього стилі. Якщо ж необхідно забезпечити підтримку старих браузерів, в таблиці стилів можна використовувати атрибут class. Порівняйте це з рішенням, запропонованим HTML 5, в якому до нових тегів неможливо застосовувати стилі в Internet Explorer 6 і 7. Тепер ви бачите, що воно зворотньо сумісне в набагато меншому ступені.

Можливість розширення за допомогою атрибутів

Замість нових тегів, в HTML 5 повинні бути введені нові атрибути. Кожен з цих атрибутів буде відноситися до певної семантичної категорії. HTML, як я докладно розповідав в іншій статті, включає в себе структурну семантику, риторичну семантику, рольову (як в XHTML) та інші.

Нові атрибути можуть використовуватися так само, як і class, додаючи елементу метадані або якесь смислове значення, що описує його природу.

Це дуже схоже на атрибут role в XHTML, однак замість єдиної «зв’язки» для всіх семантичних елементів, ми повинні визначити окремі атрибути стосовно кожної семантичної категорії.

Наприклад, атрибут role в XHTML використовується таким чином:

  • Завантаження
  • Документація
  • Новини

Значенням атрибута role є список слів, розділених пропуском, і взятих зі стандартної або визначеної користувачем термінології.

Чому б просто не запозичити атрибут role? Тому що існують інші семантичні категорії, до яких не можна застосувати опис ролі, наприклад:

Він чудова людина.

Тут використано теоретично можливий атрибут «rhetoric», який може бути використаний для розмітки риторичного сенсу документа. Очевидно, що елемент, до якого він застосований, не грає ролі «іронія», хоча його вміст і є іронічним.

Ось ще один приклад. Цілком очевидно, що в HTML не вистачає способу прив’язки машинно-читаного опису до зрозумілого людині значення, наприклад, до дати. Саме це послужило приводом до відмови BBC від мікроформатів hCalendar, про що я вже говорив раніше. Наступний код:

Перше травня

не має сенсу, але щось на кшталт такого:

Перше травня

цілком можна застосувати.

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

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

– Скільки різних семантичних атрибутів має бути? Чи повинні ці категорії бути розширюваними, і якщо так, то як?
– Як будуть визначатися словники термінів?
– Чи будемо ми просто придумувати необхідні терміни, як при використанні значень класу, або ж можливі значення повинні бути стандартизовані специфікацією? Чи повинен існувати механізм додавання (і колективного використання) призначених для користувача словників, використовуючи щось на зразок профілів?
– Якщо два словника будуть конфліктувати між собою, наприклад, при співпадінні термінів, як може бути вирішена така ситуація?
– Чи потрібен нам механізм просторів імен, або щось подібне?

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

Принаймні, сподіваюся, очевидно, що просте додавання нових елементів не сприятиме розширенню семантичних можливостей HTML.

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