Кратко

  • W3C утвердил новый устав Web Performance Working Group 10 августа 2026 года; срок его действия заканчивается 1 августа 2028 года.
  • Перед включением новой функции в спецификацию, поддерживаемую как Candidate Recommendation, желательно получить выражение интереса как минимум от двух разработчиков реализаций.
  • При отсутствии двух заявлений функцию всё равно можно внести в Candidate Recommendation Draft, но она должна быть помечена at risk.
  • Для перехода дальше Candidate Recommendation ожидаются две независимые совместимые реализации каждой функции и открытые тесты; общий W3C Process сохраняет публично мотивируемое исключение.
  • В карточке состояния функции нужно отдельно хранить интерес, принятие рабочей группой, риск, происхождение реализаций, версию тестов и решение о переходе.

Формулировка стала точнее

Web Performance Working Group занимается методами наблюдения и улучшения загрузки, отрисовки, реакции на действия, использования памяти и других характеристик приложений. 10 августа W3C сообщил об утверждении устава и пригласил участников. Новый срок установлен до 1 августа 2028 года.

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

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

Для этого устав называет более поздний критерий. За пределы Candidate Recommendation спецификация должна переходить с двумя независимыми совместимыми реализациями каждой функции, проверяемыми открытыми наборами тестов. Открытый набор нужен для каждой функции. В одном случае фиксируется готовность рассматривать и инвестировать, в другом — воспроизводимый результат независимых систем.

Эти сведения нельзя превращать в две степени одной и той же поддержки.

Четыре состояния одной функции

Сначала предложение может развиваться в Web Platform Incubator Community Group. Там появляются варианты, сценарии и код, но Web Performance Working Group ещё не обязана считать работу своей.

Затем возможно принятие рабочей группой. Устав говорит, что предложение WICG, реализованное и доступное хотя бы в одном крупном браузере и получившее дополнительную поддержку, может быть принято WebPerf. Такое решение определяет институциональное место дальнейшей работы. Оно не создаёт вторую независимую реализацию автоматически.

Третье состояние — включение в Candidate Recommendation Draft. Функция без двух выражений интереса может находиться там с пометкой at risk. Она открыта для дальнейшего опыта, но её сохранение при следующем переходе не обещано.

Четвёртое состояние связано с реализациями и переходом. W3C Process использует Candidate Recommendation для сбора практического опыта. Он также различает CR Draft, публикующий намеченные изменения для рецензирования, и CR Snapshot с иной переходной и патентной ролью. Фраза «уже в CR» не сообщает ни тип документа, ни состояние конкретной функции.

Одна отметка поддержки может обозначать благожелательный комментарий, эксперимент под флагом, решение WG, частично пройденные тесты или полноценную совместимость. Без ссылки на исходный факт она мало пригодна для решений.

Публичный ответ Mozilla не обещает лишнего

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

Публичное поле с графиком реализации осталось без конкретной даты.

Именно так следует читать документ: это общий интерес к деятельности группы, а не перечень обязательств по функциям. В нём не названы две реализации конкретного API, выпуск браузера или срок включения по умолчанию. Называть ответ завершённой реализацией означало бы дописать обещание за его автором.

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

At risk — не прогноз провала

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

Пометка должна относиться к точной функции и редакции. Если она исчезла, история обязана объяснить, появился ли второй интерес, готовая реализация, сужение, удаление или только новая структура текста.

Тестам тоже требуется версия. Сообщение о двух прошедших браузерах неполно без версии продукта и движка, настройки по умолчанию, ревизии Web Platform Tests, охвата и остаточных ошибок. Два бренда могут использовать общий код. Независимость нужно обосновывать устройством реализаций, а не количеством логотипов.

Исключение — отдельный публичный объект

Устав называет две реализации ожидаемым условием. Общий W3C Process разрешает Team при веской причине одобрить переход с минимальным опытом, но требует опубликовать решение и объяснение.

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

Различение публикации и принятия у Heng Lu полезно против завышения институциональных ярлыков: документ не заменяет внедрение, проверку и использование. Но и работающий код не присваивает себе статус W3C Recommendation. Операционный факт и формальное решение должны стоять рядом, сохраняя разные источники полномочий.

Карточка доказательств

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

  • стабильный идентификатор и неизменяемую редакцию спецификации;
  • применимые версии устава и W3C Process;
  • каждое публичное выражение интереса с организацией, датой, объёмом и источником;
  • исследовательский, запланированный, реализованный, отозванный или недатированный характер заявления;
  • решение Working Group и принятую редакцию предложения;
  • URI и историю пометки at risk;
  • продукт, движок и версию реализации, а также основание считать её независимой;
  • редакцию открытого набора тестов, охват и датированные результаты;
  • переход, возражения и опубликованное исключение;
  • следующую проверку, исправление и замену.

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

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

Источники

  1. W3C — утверждение устава и приглашение к участию
  2. W3C — утверждённый устав Web Performance Working Group
  3. W3C — различия проекта и утверждённого текста
  4. W3C — публичное объявление о рассмотрении проекта
  5. Публичный архив W3C — ответ Mozilla
  6. W3C — Process Document
  7. W3C — публикации Web Performance Working Group
  8. W3C — страница Web Performance Working Group
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption