Спецификации HTML5 W3C и WHATWG — документированные различия
Перевод статьи W3C vs. WHATWG HTML5 Specs — The Differences Documented с сайта developer.telerik.com, c разрешения автора — Аурелио Де Роса.
Несколько недель назад HTML5 получил статус W3C-рекомендации. Я воспользовался этим событием, чтобы обсудить на SitePoint пять интересных, но уже устаревших вещей. Проблема в том, что W3C-спецификации — это лишь одна сторона медали. Начиная с этой версии HTML, разработчики и производители браузеров могут выбирать между двумя разновидностями одного и того же языка разметки: спецификациями, разработанными консорциумом W3C, и тех, что разработаны WHATWG.
По большей части эти спецификации одинаковы или очень похожи, но, с годами между ними возникает всё больше и больше различий. Стоит ли вам беспокоиться об этом? В большинстве случаев не стоит, потому что либо они мало что изменят для вас и ваших проектов, либо разработчики браузеров будут поддерживать оба стандарта. Однако, в краткосрочной перспективе другие различия могут иметь важное значения для вас, т.к. они влияют на реализацию нововведения. У каждого разработчика браузера есть свой собственный взгляд на то, какой спецификации следовать. Например, Дэвид Бэрон из Mozilla недавно заявил:
Если HTML-спецификации W3C и WHATWG различаются, то мы стараемся следовать спецификации WHATWG.
В этой статье мы пройдёмся по некоторым различиям между спецификациями W3C и WHATWG, и в конце каждого раздела я выскажу свою точку зрения. Эта статья не претендует на роль исчерпывающего списка различий, но ее должно хватить, чтобы вникнуть в эту проблему.
«HTML5» против «Живого стандарта HTML»
Давайте начнём нашу дискуссию о различиях с простой темы: название стандарта. Версия спецификации WHATWG в начале 2011 года была переименована в «HTML», отбросив цифру «5» в конце названия. Затем в дальнейшем она была переименована в «Живой стандарт HTML», чтобы указать на то, что впредь она будет находиться в постоянной разработке, не ссылаясь на какой-то определённый номер версии.
W3C-спецификации, напротив, всё ещё используют номера версии, как я упоминал в начале этой статьи — последняя стабильная версия — «5», соответственно «HTML5». Как следствие этого шага, консорциум теперь активно развивает новую версию стандарта, известную как «HTML5.1». В HTML5.1 обсуждаются некоторые элементы и атрибуты, которые не попали в HTML5, например, элемент dialog и новые типы input — month и week.
Моё мнение
Я думаю, что нынешний мир действительно отличается от ранних 2000-х, потому что технологии развиваются в еще более бешеном темпе, особенно в вебе. Так что есть основания чувствовать непрерывность, отбросив все номера версий. Однако не каждый браузер обновляется автоматически (широко используется термин «вечнозелёный браузер»), и периодичность выхода новых версий у разных браузеров разная, поэтому всё ещё имеет смысл привязать набор возможностей к одной или нескольким версиям браузеров.
Я считаю, что до тех пор, пока каждый браузер не примет политику быстрых релизов и автообновление, наличие версии позволит разработчикам лучше планировать свою работу. Не с целью создания сайтов, определяющих версию браузера, чтобы подключить ту или иную функцию (для этого лучше воспользоваться подходом определения реально поддерживаемых браузером функций), а потому, что для конкретной версии браузера мы можем получить статистику ее использования. С помощью таких статистик можно оценить, пора ли уже включать определенную функцию в свой проект. Да, полифилы и «заплатки» могут помочь, но нужно же учесть, насколько вы готовы утяжелить свой сайт?
Элемент main
Элемент main — один из последних элементов, добавленных в спецификации, и его значение может быть разным в зависимости от версии. Спецификация W3C описывает его, как главное содержимое страницы — содержимое, которое описывает основную тему страницы или центральную функциональность приложения. Спецификация также утверждает, что документ не должен содержать более одного элемента main и что элемент main должен быть привязан к ARIA role="main" или к эквиваленту в API вспомогательных технологий.
Простой пример использования, основанного на этой спецификации, выглядит так:
<body>
<header>
<h1>Main title</h1>
</header>
<main>
<article>
<h1>Main title</h1>
<p>This is the content of this section</p>
<footer>
The author of this content is Aurelio De Rosa
</footer>
</article>
</main>
<footer>
<small>Copyright © Aurelio De Rosa 2014</small>
</footer>
</body>
Спецификации WHATWG не закрепляют никакого семантического значения за элементом main и описывают его как контейнер для основного содержимого другого элемента. Если вы придерживаетесь спецификации WHATWG, то вы не ограничены в количестве используемых элементов main. Следовательно, если у вас на странице есть несколько элементов article, вы могли бы разметить содержимое каждого article элементом main.
Пример использования, основанного на спецификации WHATWG, может выглядеть так:
<body>
<header>
<h1>Main title</h1>
</header>
<main>
<article>
<h1>Main title</h1>
<main>
<p>This is the content of this section</p>
</main>
<footer>
The author of this content is Aurelio De Rosa
</footer>
</article>
</main>
<footer>
<small>Copyright © Aurelio De Rosa 2014</small>
</footer>
</body>
Заметьте, что в вышеприведённом коде я использовал элемент main дважды.
Моё мнение
В отношении элемента main я за W3C, потому что сомневаюсь, что у людей есть потребность в нескольких основных областях в документе. Кроме того, я помню, что Стив Фолкнер (редактор спецификаций W3C) в почтовой рассылке несколько раз призывал Йена Хиксона (редактора спецификаций WHATWG) показать ему данные, которые доказали бы необходимость в использовании нескольких главных областей. Результат всегда был один и тот же — во всех случаях редактор WHATWG не мог предоставить такие данные.
Элемент hgroup
Элемент hgroup предназначен для группировки набора из одного или более элементов h1-h6, что полезно, чтобы сгруппировать заголовок раздела и сопутствующий подзаголовок.
Этот элемент был введён для лёгкого создания подзаголовков, и чтобы решить важную проблему с алгоритмом структуры документа. Фактически, при группировке нескольких заголовочных элементов в hgroup, структурный алгоритм должен был, по задумке, скрыть всё кроме заголовка самого верхнего уровня в группе из полученной структуры документа.
Пример, показанный ниже, взят из моей статьи «5 устаревших вещей в HTML5»
<article>
<hgroup>
<h1>5 deprecated features of HTML5</h1>
<h2>Sometimes specifications are changed
and you need to refactor your code</h2>
</hgroup>
<p>In this article we'll discuss...</p>
</article>
В апреле 2013 года этот элемент был удалён из спецификации W3C из-за отсутствия реализации, примеров реального использования, а также способствовал плохому стилю разметки. Напротив, спецификация WHATWG всё ещё включает hgroup.
Моё мнение
Как было указано в цитируемой статье, я был фанатом этого элемента, но перестал его использовать по двум причинам. Во-первых, из-за того, что я в основном являюсь сторонником спецификации W3C. А во-вторых, я тоже заметил, что браузеры не очень заинтересованы в его реализации.
API веб-уведомлений
API Веб-уведомления определяется, как API для уведомлений конечного пользователя. Уведомление позволяет оповещать пользователя вне контекста веб-страницы, например, о таком событии, как передача электронной почты. С помощью этого API можно предоставить уведомление вашим пользователям о том, что они получили электронное письмо, или уведомить их в случае, если произошло событие, на которое им следует обратить внимание. Как конкретные примеры можно привести, если кто-то упоминает пользователя в твиттере или отправляет фотографию с вами на Facebook или Google+.
Простой пример использования этого API показан ниже:
Notification.requestPermission(function() {
var notification = new Notification('Email received', {
body: 'You have a total of 3 unread emails'
});
notification.onshow = function() {
console.log('Notification shown');
};
});
API веб-уведомлений описаны в обеих спецификациях, как в W3C, так и в WHATWG, но но между двумя версиями есть некоторые различия. В частности в спецификации WHATWG отсутствуют события onclose и onshow. Таким образом, W3C-спецификации определяют четыре события (onclick, onclose, onerror и onshow), а спецификации WHATWG только два (onclick и onerror).
Если у вас есть желание более подробно изучить различия между версиями этого API и узнать, какова его поддержка в основных браузерах, то вы можете посмотреть мою статью «Состояние API Веб-уведомления».
Моё мнение
Различий между спецификациями не так много, но они влияют на то, как вы можете решать задачи. В данном случае я также поддерживаю спецификации W3C, так как думаю, что могут возникнуть случаи когда нужно совершать действия по событию close, что невозможно, если следовать спецификациям WHATWG.
Заключение
В этой статье мы обсудили несколько самых важных различий между спецификациями W3C и WHATWG. Как вы видите, учитывая количество элементов и API, определённых в спецификациях, различий между ними пока не так уж много. Учитывая это, я не беспокоюсь о будущем, так как уверен, что, в конце концов, спецификации будут просто соответствовать действительности. Это означает, что независимо от того, что было указано обеими группами при появлении функции, браузеры и разработчики в силах поспособствовать успеху той или иной версии. Таким образом, браузеры и разработчики — игроки, которые решают, какая спецификация для них «выигрышная» путём её реализации или принятия. Так что для каждой спорной функции «проигравшая» группа в конечном итоге адаптирует спецификации в соответствии с реальностью.
Под занавес стоит отметить, что в случае, если вы захотите открыть для себя ещё несколько различий, то можете посмотреть их на странице «Различия между спецификациями W3C HTML5.1 и WHATWG LS» на W3C Wiki.
P.S. Это тоже может быть интересно: