Остановите войну в Украине!

Как ор­га­ни­зо­вана веб-плат­фор­ма

Редактировать статью на Гитхабе

Виталий Зюзин

Редактура Никита Дубко Вадим Макеев

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

Веб-платформаСкопировать ссылку

«Веб-платформа» — это набор стандартизированных API (HTML, CSS, JavaScript, SVG…), которые разработчики используют для построения сайтов и веб-приложений. Помимо «корневых» технологий платформа включает ещё и локальные браузерные API, которые добавляют в браузер новую функциональность: DOM, Console, Fetch и другие.

СтандартыСкопировать ссылку

Как всё работает в браузере, описано в специальных документах — спецификациях. Это подробные инструкции для разработчиков, как должна работать какая-то определённая фича. Например, как должны строиться сетки на флексах или как должен работать console.log.

СпецификацииСкопировать ссылку

Спецификаций в веб-платформе много. Спеки создаются в специальных организациях: W3C, WHATWG, Ecma International, OpenJS Foundation и другие — в них и создаются HTML, CSS, SVG, JS, Node.js. Дальше мы подробнее поговорим о том, как работают W3C и WHATWG.

W3CСкопировать ссылку

World Wide Web Consortium — международная организация, в штате которой примерно 60 человек из мировых университетов (MIT, ERCIM, Keio University, Beihang University). Также в W3C есть членство для внешних компаний.

На апрель 2021 в W3C состоит 438 компаний-членов: производители браузеров (Mozilla, Google, Apple, Samsung), софтверные компании (Adobe, Zoom), технологические гиганты (Amazon, Facebook, Visa, Alibaba), сервисы (Airbnb, Netflix, Shopify), железо (Huawei, Intel) и другие.

Чтобы иметь членство W3C, компании нужно платить членские взносы (для бедных стран — меньше, для богатых — больше). Например, если небольшая российская компания захочет вступить в «клуб» W3C, то это в 2021 году будет стоить минимум 1950 € в год (для больших компаний в 10 раз больше).

Компании отправляют своих сотрудников для работы в W3C. Вместе со штатными сотрудниками W3C приглашённые делегаты формируют рабочие группы (WG, Working Group).

Работа в FAANG (аббревиатура из названий крупнейших компаний Facebook, Amazon, Apple, Netflix, Google — прим. редактора) — не единственный способ попасть в рабочую группу W3C. Группа может включать и приглашённых экспертов (Invited Expert), которые никак не аффилированы с бизнесом, но являются крутанами в своей области. Все рабочие группы собираются на ежегодной сходке TPAC (Technical Plenary), которая проходит осенью.

Рабочая группа CSS в W3CСкопировать ссылку

Как устроена рабочая группа, на примере CSS Working Group.

В ней есть председатели, штатные сотрудники W3C, делегаты из внешних компаний (FAANG и другие) и приглашённые эксперты, например: Рэйчел Эндрю, Элика Этемад, Лия Веру, Джонатан Нил. Внешние эксперты приглашаются по предложению участников рабочей группы.

Среди всех участников выделяется три роли:

  1. Редакторы спецификаций — отвечают за модули спецификаций, следят за ишью, получают фидбек, пишут спеку и тащат прогресс по своим модулям спек (иногда у спеки только один редактор, иногда — несколько);
  2. Остальные члены рабочей группы (не редакторы) — участвуют в дискуссии, брейнштормят, принимают коллективные решения;
  3. Сообщество сочувствующих www-style — это как непосредственно участники группы, так и в целом все заинтересованные в CSS люди: они комментируют и критикуют предложения, запрашивают фичи и объясняют юзкейсы, поднимают вопросы, участвуют в обсуждениях и дают фидбек редакторам спек.

Контент CSS-спецификаций живёт в репозитории github.com/w3c/csswg-drafts. Там же заводятся ишью и проводятся публичные дикуссии по контенту. Вот, например, увлекательное обсуждение CSS-нестинга.

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

Спецификации в W3CСкопировать ссылку

Все спецификации W3C опубликованы в одном месте по адресу w3.org/TR.

Спеки проходят такие формальные стадии развития (некоторые промежуточные технические стадии упростил):

  1. Working Draft (WD) — зафиксированная версия черновика спеки для ревью сообществом.
  2. Candidate Recommendation (CR) — сигнал для финального ревью сообществом, сбор опыта реализации спеки в браузерах.
  3. W3C Recommendation (REC) — все довольны, спека доделана, опубликована финальная версия.

Текущая версия черновика называется Editor’s Draft (ED) и может быть достаточно сырой, но она самая живая из всех — над ней работает редактор спеки.

Спецификации по CSSСкопировать ссылку

Если отфильтровать все спеки по тегу CSS, то получится больше сотни. Большая часть из них — черновики WD, меньшая — рекомендации REC и CR.

После публикации единой монолитной спецификации CSS 2.1, рабочая группа решила распилить её и дальше развивать отдельные независимые модули. Также появилась идея собрать из отдельных модулей общий сборник «CSS 3» и дальше развивать отдельные модули и двигать их по уровням независимо друг от друга.

К примеру, в CSS 2.1 был раздел Color. Поэтому в рамках CSS 3 появился отдельный модуль — CSS Color Level 3. Дальше он будет двигаться к Level 4, потом к 5 и так далее.

Если в спеке CSS 2.1 изначально какой-то фичи не было, например, кастомных свойств или флексов, то новые спецификации начинают нумероваться с первого уровня: например, CSS Custom Properties for Cascading Variables Module Level 1 или CSS Flexible Box Module Level 1.

Чтобы не потеряться в обилии спек, рабочая группа CSS время от времени публикует «срез» состояния CSS — Snapshot. Последний из опубликованных — CSS Snapshot 2020. Это список всех спек, про которые в 2020 году можно сказать, что это и есть весь современный стабильный CSS.

Процесс работы над спеками CSSСкопировать ссылку

Как показала практика, работа над CSS-спеками не всегда укладывается в формальную линейную однонаправленную схему WD → CR → REC. Иногда развитие спеки в ответ на полученный фидбек двигается назад, а не вперёд. Поэтому есть более неформальное и близкое к жизни описание стадий работы над спеками, которое показывает стабильность спецификации:

  1. Exploring (ранний WD): нестабильная версия, где всё ещё устаканивается и меняется. Нужен для совместной работы редактора спеки и рабочей группы.
  2. Revising (средний WD): модуль в основном готов, но спека ещё нуждается в нескольких циклах публикации и ревью. В конце этой стадии рабочая группа фиксирует контент спеки перед переходом на формальный CR.
  3. Refining (поздний WD): спека уже в основном стабильна и готова для перехода на CR, но ещё нуждается в шлифовке и полировке.
  4. Testing (ранний CR): на этом этапе рабочая группа уверена, что спека достаточно полна и точна, чтобы её начинать имплементировать и писать тесты, так как для дальнейшего развития спеки нужен уже опыт имплементации в браузерах и тест-кейсы.
  5. Stable (поздний CR): на этой стадии у рабочей группы есть достаточно полученного опыта тестирования и имплементации спеки, сама спека стабильна и надёжна, минорные ишью появляются нечасто. Такая версия спеки может быть включена в Snapshot.
  6. Completed (PR, REC): тесты и отчёты об имплементации готовы, изменений больше не предвидится (кроме листинга опечаток).

Все CSS-спеки, сгруппированные по таким стадиям, опубликованы на странице CSS current work.

WHATWGСкопировать ссылку

Но не W3C единым жива веб-платформа. В 2004 году от W3C из-за разногласий по поводу будущего HTML откололась группа разработчиков стандартов. Эта группа назвалась WHATWG — Web Hypertext Application Technology Working Group. В W3C собирались остановить работу над HTML в угоду XHTML 2 — новой версии XHTML, обратно не совместимой с HTML 4 и XHTML 1. В WHATWG считали, что нужно продолжать развивать HTML и стандарты для создания веб-приложений. Они форкнули HTML и развили его до того самого HTML 5, тем самым выиграв у W3C.

До 2019 существовало две разные параллельные спецификации HTML, но потом W3C и WHATWG помирились и договорились работать вместе над «вечнозелёной» спекой HTML.

Помимо HTML в WHATWG работают над такими фичами: Compatibility, Console Object, DOM, Encoding, Fetch, Fullscreen, URL и XHR. Все спецификации опубликованы на сайте spec.whatwg.org.

Спеки WHATWG живут в репозитории github.com/whatwg.

Процесс работы WHATWGСкопировать ссылку

В отличие от W3C, WHATWG — открытое и бесплатное сообщество. Любой желающий может участвовать в развитии спек. Работа ведётся на Гитхабе.

Все стандарты WHATWG — «вечнозелёные», то есть не имеют версий, а всегда «доделаны». В WHATWG сравнивают разработку спек с разработкой ПО — софт тоже постоянно разрабатывается и меняется.

У каждого стандарта в идеале есть:

  • редактор или несколько;
  • активное сообщество контрибьюторов;
  • лог изменений;
  • ишью-трекер;
  • тесты.

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

Всего в организации на Гитхабе в июне 2021 состоит 81 человек.

Тесты веб-платформыСкопировать ссылку

Когда рассказывают о веб-спецификациях, мало говорят про тесты. Вот есть текст спеки, вот её внедрили в браузере, это ок. А как узнать, что ничего старого при этом не поломалось? Как оценить, что внедрение корректное и спеку поняли правильно?

Тесты нужны, чтобы помочь мейнтейнерам софта (браузеров) проверить корректность своей работы: найти баги, проблемы совместимости с другими браузерами. Также они помогают приоритизировать работу над определённой группой более критичных багов. У веб-платформы есть свой набор тестов, который открыто пишется сообществом. Они удобно разделены по названиям фич и внутри структурированы по разделам спецификаций.

Реалии таковы, что браузеры не проходят все тесты на 100% и вряд ли будут когда-то их проходить. Новые фичи появляются в браузерах, а за ними приходят баги, спеки и внедрения допиливаются — всё это нормально. К примеру, в июне 2021 из 41761 тестов в Chrome не проходят 510 тестов, в Firefox — 1377, а в Safari — 3859.

Графики результатов тестов, сгруппированные по фичам, есть на сайте wpt.fyi. Вот такая, к примеру, ситуация с поддержкой гридов в браузерах.

Тесты, помимо пользы для разработчиков браузеров, дают и обычным разработчикам возможность оценивать фичи перед использованием. Обычно разработчики смотрят на статистику внедрения фич на сайте Can I Use. Так можно получить ответ на вопрос: есть ли фича в определённом браузере. Но кроме формального внедрения фичи стоит учитывать:

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

Как контрибьютить в веб-платформуСкопировать ссылку

Самый простой вариант, как въехать в тему — подтянуть английский и заняться багами:

Ещё