Фантастические веб-спецификации и где они обитают

Многие разработчики, что уж скрывать, недолюбливают спецификации. Одни считают их скучными. Другим они вообще кажутся монстрами, не иначе как порожденными мифической Ехидной (невероятно, но это отчасти правда: именно так — Echidna — называется система автопубликации, используемая в W3C).

Новичка они могут запутать, как лешие, заманить в ловушку, как сирены, и озадачить неразрешимыми загадками, как Сфинкс. Зато о тех, кто проник в их тайны и подчинил себе их мощь, порой слагают легенды фронтенда.

Эта статья расскажет об основных опасностях, подстерегающих новичка в царстве спецификаций, откуда их можно ждать, по каким признакам их можно распознать, и о том, как «приручить» спецификации и сделать их своими верными слугами и помощниками.

Спецификации-оборотни

Стандартами для веба занимается немало организаций. Есть Международная организация по стандартизации (ISO). Есть Международная электротехническая комиссия (IEC). Есть ECMA — некогда скромная «Европейская ассоциация производителей компьютеров», а ныне всемирная «кузница» стандартов Javascript. Есть Инженерный совет интернета (IETF) — с его трудами, вида RFC-какие-то цифры, вы тоже наверняка не раз сталкивались. Есть отдельные группы представителей фирм или просто специалистов-энтузиастов, разрабатывающих конкретный стандарт — например, schema.org или микроформаты (впрочем, первых «взял под крыло» W3C на правах общественной группы). Наконец, есть WHATWG… но о ней чуть позже отдельно.

Конечно же, самая известная и узнаваемая организация, для многих ставшая синонимом веб-стандартов — Консорциум веба или WWW-консорциум, W3C. Где «w3» («w трижды») — лишь еще большее сокращение для «www». Не всё, что начинается с «w3», имеет какое-то отношение к W3C. Бывают просто похожие названия — случайно или нарочно. Adidas и Abibas, Nokia и Nokla, W3C и W3SchoolsОстерегайтесь подделок!

Есть масса полезных для веб-разработчика учебных и справочных ресурсов. W3Schools — один из них, вовсе не лучший (когда-то был вообще ужасным, сейчас заметно исправился). Но эти ресурсы — не спецификации, тем более не стандарты. Фраза типа «так написано в спецификации W3Schools» однозначно выдает… в лучшем случае жертву заблуждения.

Справедливости ради, справочные и учебные материалы обычно написаны понятнее и доступнее. Пожалуй, лучший ресурс с такими материалами — MDN, по сути Википедия фронтенда, над которой теперь сообща работают все лидеры отрасли. И хорошо, что именно на эти ресурсы ведут первые ссылки в поисковиках по названию HTML-тега или CSS-свойства. Но даже в них попадаются переупрощения, неточности и устаревшие данные. Они могут попросту не успевать за изменениями настоящих спецификаций. Тем более переводы.

Короче говоря: отличайте спецификации от учебно-справочных материалов.

Спецификации-зомби

У большинства спецификаций W3C, на которые мы попадаем из поиска или по ссылкам из статей и справочников, адрес начинается так: w3.org/TR/что-то. TR означает «Technical Reports» — технические отчеты. Название странное, но понять его логику можно: рабочая группа по какой-то технологии прицельно изучает некую проблему и время от времени отчитывается, какие решения для этой проблемы найдены.

У каждой публикации в TR есть статус: если это еще сырая заготовка с кучей спорных мест, или вовсе первая публикация по этой технологии — это рабочий черновик. Когда решение как следует проработано и надежно реализовано, W3C может рекомендовать его всей отрасли — такой технический отчет становится рекомендацией (у W3C это синоним стандарта). До этого спецификация успевает побыть в статусах кандидата в рекомендации и предложенной рекомендации. Если же работа над спецификацией зайдет в тупик, то она публикуется со статусом «Заметка» (Working Group Note).

Все опубликованные технические отчеты W3C, независимо от статуса, хранятся вечно. У каждой версии есть постоянная длинная ссылка типа https://www.w3.org/TR/2008/WD-html5-20080610/, где зашифрованы ее статус (в примере — Working Draft, рабочий черновик) и дата публикации (10 июня 2008 г.). Такие ископаемые версии порой «всплывают» в поисковиках, по ссылкам в старых статьях и т.п. Иногда на них задним числом вешают предупреждающую плашку, что материал устарел (как на CSS2.1), но часто — нет (как в день публикации статьи было на HTML5.1).

Поэтому даже настоящая спецификация на сайте W3C может оказаться давно и безнадежно неактуальной. Остерегайтесь просроченных продуктов, смотрите на дату!

Кроме длинных ссылок для истории, для каждого <название технологии> есть ссылка вида w3.org/TR/<название технологии> (напр., https://www.w3.org/TR/html/) — последняя опубликованная версия («Latest published version»). В «шапке» каждой спецификации указана постоянная ссылка этой конкретной версии (для архива/истории), последней опубликованной версии и одной-двух предыдущих (обычно). А еще — на текущий редакторский черновик («Editor’s Draft», ED).

Многие думают, что «редакторский черновик» — что-то совсем сырое, какой-то еще более ранний статус, чем «рабочий черновик» в TR. Но редакторский черновик есть и у зрелых спецификаций. Это просто текущая рабочая версия документа. Как master-ветка в git, от которой время от времени «отпочковываются» релизы. В ней в реальном времени исправляются найденные ошибки и добавляются новые уточнения. Поэтому многие знатоки советуют сверяться именно с редакторским черновиком, а не архивными копиями из TR.

И не пугайтесь, если ссылка на редакторский черновик ведет не на домен w3.org. А, например, на csswg.org (домен рабочей группы CSS — подразделения W3C, занимающегося именно стилями), а то и вовсе на Гитхаб. Это не баг, а фича!

Короче говоря: пользуйтесь только свежими версиями спецификаций, избегайте архивных версий. Лучше всего — редакторскими черновиками. В крайнем случае — последними опубликованными версиями, если они не старше полугода.

Спецификации-призраки

На статусах и датах путаница не кончается: у одной технологии может быть несколько редакторских черновиков!

Например, у нас есть CSS-модуль каскада и наследования 4 уровня, уже опубликованный в статусе кандидата в рекомендации, с редакторским черновиком по адресу https://drafts.csswg.org/css-cascade/ (на всякий случай: CSS — всё еще каскадные таблицы стилей!). Но есть такой же модуль 3 уровня: опубликован он в точно таком же статусе и в тот же день. И у него есть свой редакторский черновик: https://drafts.csswg.org/css-cascade-3/. Какой из этих черновиков «более актуальный»?

Чаще всего помогает такое правило: актуальнее то, куда ведет ссылка без цифры, как бы «на технологию вообще». Например, вышеупомянутый /css-cascade/ (без цифры) ведет на модуль 4 уровня. Значит, скорее всего именно это — текущая спецификация, а /css-cascade-3/, с цифрой — уже слегка вчерашний день (ничего нового там уже не появится, будут лишь уточняться формальные детали). А вот просто /css-animations/ ведет на модуль спецификации 1 уровня, значит актуален именно он, а /css-animations-2/ — пока еще слишком сырая заготовка, сборник «идей на будущее».

С CSS нам вообще повезло: у нас есть список всех редакторских черновиков https://drafts.csswg.org/, в котором для всех модулей, существующих параллельно в двух и более «ветках», напротив актуальной версии есть приписка «Current work».


Рис. 1. Если в работе одновременно несколько модулей разных уровней, актуальный текущий помечен как «Current work»

А за зрелостью модулей удобно следить еще и по «светофору» на странице «Текущая работа»: зеленое — значит, скорее всего, более-менее готово, красное — лучше повременить. Только будьте осторожны со статусом «Note» («Заметка»): он тоже зеленый (работа над модулем закончена), но это может значить как не имеющий нормативного статуса, но всё же готовый документ (напр. http://www.w3.org/TR/CSS, описывающий состояние «CSS вообще» на текущий год), так и заброшенный «полуфабрикат» зашедшей в тупик работы (как какой-нибудь https://www.w3.org/TR/css3-marquee/). Такой вот загадочный статус..:)


Рис. 2. Примерная расшифровка «светофора» статусов модулей на странице «Текущая работа» Рабочей группы CSS

Короче говоря: чем лаконичнее адрес спецификации (чем меньше в нем лишних цифр), тем лучше. Для CSS-спецификаций сверяйтесь со страничками «Текущая работа» и пометками «Current work» в списке редакторских черновиков. Осторожнее с документами в статусе «Note» («Заметка»).

Спецификации-тролли

Старые версии технических отчетов W3C хранятся вечно не просто так. Одна из задач открытых веб-стандартов — защитить технологии от патентных троллей, чтобы все участники рынка были в равных условиях. Для этого у W3C давно налажена целая патентная политика. У WHATWG — хоть не так давно — тоже.

Патентным юристам часто приходится перелопачивать горы источников, тщательно сверяя все заковыристые формулировки. Иногда это занимает месяцы и годы. Всё это время документ меняться не должен. Вот для чего нужны вечно хранящиеся технические отчеты!

У документов, где замешаны юристы — среди которых попадаются те еще патентные тролли! — есть еще одна противная черта: сложный и запутанный язык, которым они написаны. С кучей перекрестных ссылок, сносок и уточнений. Вдобавок, масса терминов определяется через другие документы. Которые тоже могут меняться и устаревать. С этим особо ничего не поделать. Чтобы стать гуру спецификаций, этот язык надо просто освоить. Методом практики, другого, видимо, нет. Не случайно в спецификации HTML, в специальном разделе «как читать эту спецификацию», сказано буквально следующее:

Эту спецификацию следует читать так же, как и все другие спецификации. Сначала от корки до корки несколько раз. Потом в обратном направлении, минимум один раз. Затем нужно прочитать ее, выбирая случайные разделы в оглавлении и переходя по всем перекрестным ссылкам.

К счастью, помимо сухих формулировок для патентоведов (и не менее сухих словесных описаний алгоритмов для разработчиков браузеров), в спецификациях есть живые примечания простым языком, примеры и иллюстрации. А если их недостаточно — всегда можно добавить ещё (как — об этом чуть ниже).

Короче говоря: просто больше читайте спецификации:)

Спецификация — двухголовая гидра

Много путаницы вызывало то, что спецификаций HTML две, причем разные: W3C HTML5 (его редакторский черновик — https://w3c.github.io/html/) и «живой стандарт» WHATWG HTML («вечнозеленый» и «живущий» по адресу https://html.spec.whatwg.org). Кому верить?

История отношений между W3C и WHATWG — тот еще сериал, тянущийся с середины 2000-х. Сама «Рабочая группа по технологиям для гипертекстовых веб-приложений» (так WHATWG расшифровывается) возникла как ответ разработчиков браузеров на вопиющий отрыв W3C (с его тогдашними мечтами о скорой повальной XMLизации) от реальности. Реальные браузеры должны были справляться с существующим контентом, а тот часто не был совместим ни с каким стандартом и держался лишь на нестандартных костылях. Понадобился прагматичный стандарт, совместимый как с тем, что есть, так и с тем, чего хочется в будущем. Большую часть громадной работы по анализу и документированию реального положения дел в вебе, итогом которой и стал HTML5, проделал один человек — Иэн Хиксон.

Какое-то время WHATWG и W3C пытались работать над стандартом вместе — одни непрерывно вносили новые фичи, вторые, в привычном неторопливом обсуждении, улаживали проблемы с патентами и прочим. Но у них оказалось слишком разное видение задач спецификации, разный подход к ее структуре (гигантский монолит у WHATWG против модульности у W3C) и редактированию, на всё это со временем наслоились разногласия по мелочам и, увы, личные обиды с обеих сторон…

Долгое время ключевым преимуществом W3C была его патентная политика. Но WHATWG выбила у него и этот козырь, заведя свою. И вот недавно противостояние закончилось: стороны подписали общий меморандум, больше похожий на капитуляцию W3C. WHATWG победила. К счастью, многие из важнейших разногласий (например, сколько на странице может быть элементов <main>) стороны успели устранить еще до этого.

Большим плюсом W3C-версии было то, что сведения о доступности тех или иных элементов (дефолтные ARIA-роли и т.д.) «интегрированы» в саму спецификацию (во многом стараниями Стива Фолкнера, для которого это очень близкая и любимая тема). Но и WHATWG-версия ссылается на соотв. стандарты W3C (сам WAI-ARIA, использование ARIA в HTML и дефолтные соответствия для HTML-элементов в API доступности основных платформ) как на нормативные требования. Эти стандарты здорово помогают понять практическое значение многих элементов. И мало того: именно в них, похоже, скрыт ключ к пониманию пресловутой семантики, о которой вечно столько споров (на эту необъятную тему я, пожалуй, напишу отдельную статью:). Так что не проходите мимо них!

Короче говоря… в общем, думайте сами, решайте сами. Будущее определенно за стандартом WHATWG, но про стандарты W3C по доступности в любом случае не забывайте!

Как приручить спецификацию

Все плюсы открытого кода

Внимательные читатели заметили, что многие (на деле почти все) редакторские черновики спецификаций хостятся на Гитхабе. Что это значит? А то, что веб-спецификации — это опенсорс. И в него, как в любой опенсорс, можно контрибьютить — участвовать в его разработке!

На конференции Web Standards Days в Минске в 2017-м был великолепный доклад Сергея Попова как раз об этом. Сергей раскрыл тему настолько, что мне остаётся добавить лишь один пункт.

В докладе Сергей отметил, что для участия в работе над спецификациями нужен хороший технический английский, без него никак. Так и есть — с одним важным исключением. Это исключение — тесты для спецификаций.

Тесты

Для большинства спецификаций, особенно более-менее зрелых (кандидатов в рекомендации и выше), у W3C есть официальные наборы тестов. Ссылка на тесты часто бывает в «шапке» самой спецификации, плюс их всегда можно найти в специальном разделе сайта W3C (тесты к спецификациям CSS — здесь: https://www.w3.org/Style/CSS/Test/). Даже если вы просто на досуге откроете набор тестов в своих браузерах и пробежитесь по ним — это уже будет огромной помощью разработчикам спецификации: статистика реализации спецификации в браузерах, обнаружение трудных/спорных мест и многое другое. К сожалению, эти тесты очень трудно автоматизировать — правильный результат может зависеть от шрифта и т.п., и оценить правильность может лишь человек.

Типичный тест выглядит как страница с двумя вкладками: сам тест и ожидаемый результат, сверстанный по-простому. Иногда сверху написан короткий текст, что от теста ожидается — на английском, но очень простом, онлайн-переводчик должен нормально осилить. Если в обеих вкладках одинаковая картинка — тест пройден, жмите кнопку Passed. Если разная — тест провален, жмите Failed.

А еще практически любой минимальный пример кода, который ведет себя по-разному в разных браузерах или просто неочевидно — хороший кандидат в тесты к соответствующему стандарту. Браузеры будут за него благодарны. Есть целый открытый проект Web Platform Tests, с хорошими рекомендациями, как такие тесты создавать.

Важное в мелочах

Ну а если вы решили приручить какую-нибудь спецификацию всерьез, лучше всего действовать по классике. Помните? Прежде всего — запастись терпением. Сначала «просто сидеть поодаль, искоса поглядывая» (открывать редакторский черновик и выборочно просматривать какой-нибудь из его разделов), но «с каждым днем садиться чуть ближе» (внимательнее присматриваться к тексту, иллюстрациям и примерам, пробовать их у себя в браузере…). Если вы заметили опечатку в слове, или что какой-нибудь пример в каком-нибудь браузере развалился или не соответствует описанию — откройте текст файла Overview.bs этой спецификации на Гитхабе для редактирования и прямо в браузере исправьте найденную ошибку. И отправьте свой первый пулреквест с этой правкой. И не забывайте, что вы в ответе за те спецификации, которые приручили.

Для меня первым таким примером с замеченной неточностью был теперешний пример 24 в спецификации CSS Grid Layout. Я не смог пройти мимо нелепой ошибки в его разметке, а заодно не привести его в соответствие иллюстрации (до правки результат примера был бы похож на предпоследнюю картинку здесь, блок с департаментом был бы внизу). И кто знает, не сыграло ли это свою роль в том, как легко и быстро нам удалось исправить спорный момент в спецификации вскоре после релиза CSS-гридов и привести поведение браузеров с repeat(auto-fit, …) к единому правильному виду?..

Напоследок: немного спецификаческого юмора:)

Какими бы скучными ни казались спецификации на первый взгляд, их пишут живые люди, не чуждые юмора. Возможно, не все знают, что знаменитая картинка «CSS is awesome» («CSS потрясающий») используется в самих спецификациях. Бывают в спецификациях и другие «пасхалки», вроде озорного подзаголовка «Ломаем веб, по фрагментику за раз» в черновиках модуля CSS-фрагментации или «секретного уровня» в приложениях к CSS2.x (добавленного ради алфавитного порядка их первых букв:). Ну а на первое апреля эти веселые люди и вовсе дают волю фантазии: то поменяют оформление для всех спецификаций в стиле любительских сайтов 90-х, а то выпустят целый шуточный модуль (с аббревиатурой EGG — «яйцо», в смысле «пасхалка»:).

Как-то раз и я решил подключиться к веселью и завел к этому модулю первоапрельское же ишью:). Поразительно, но шутку, похоже, оценили! Помимо «лайков», мне повысили статус с «контрибьютора» до «коллаборатора» (с правом снова открывать закрытые ишью, которым я уже пару раз успел воспользоваться:)

Короче говоря: дерзайте! Пусть вам тоже повезет! И не бойтесь спецификаций — они совсем не злые и не страшные!