Кратко

  • Проект устава предусматривает для WebDriver и WebDriver BiDi Candidate Recommendation со Snapshots, непрерывные обновления на этой стадии и отсутствие намерения переходить к Recommendation.
  • Это предложенная модель работы, а не принятое решение. Оба актуальных технических отчёта остаются Working Drafts; WebDriver Recommendation 2018 года — отдельное состояние публикации.
  • W3C различает формально проверенный Candidate Recommendation Snapshot и Candidate Recommendation Draft, куда включены более новые изменения без такой же формальной проверки. Ни один из них не является стандартом W3C.
  • Воспроизводимый результат должен связывать неизменяемую версию спецификации, тип зрелости, commit и выбор тестов, сборки браузера, драйвера и клиентской библиотеки, платформу, дату и известные исключения.

Постоянная кандидатская стадия — осознанная политика

WebDriver определяет общий протокол, через который внешний процесс управляет браузером. WebDriver BiDi добавляет двусторонний канал, позволяющий браузеру отправлять события управляющей программе. Поэтому нормативный текст превращается в код сразу в нескольких независимых системах: браузерном движке, драйвере, библиотеке автоматизации и Web Platform Tests.

18 августа 2026 года W3C предложил Advisory Committee рассмотреть новый устав группы. Публичные комментарии принимаются до 18 сентября, а действующий устав продлён до 23 октября. Следовательно, новый текст ещё не принят. Его значение сейчас — в ясном описании предполагаемой политики сопровождения.

Группа намерена публиковать новейшее состояние WebDriver и WebDriver BiDi как Candidate Recommendation, включая Snapshots, и непрерывно обновлять его после достижения этой стадии. Переход к Recommendation не планируется. Речь не о временной задержке и не о незавершённом обещании, а о выбранной долгосрочной точке зрелости.

Руководство W3C объясняет, почему такая модель допустима. Опыт реализации распределён между кодовыми базами с разными планами и скоростью выпуска. Snapshots дают проверенные точки, а Candidate Recommendation Drafts позволяют интегрировать последующие изменения. Спецификация остаётся близка к коду, из которого поступает практическая обратная связь.

Но Living CR меняет нагрузку на ссылку. Recommendation обычно даёт устойчивый ориентир, одобренный W3C и подкреплённый достаточным опытом реализации. Если серия намеренно остаётся Candidate Recommendation, слов «WebDriver», «WebDriver BiDi» или даже «данная CR» недостаточно для аудита, закупочного требования или отчёта об ошибке.

Даты в уставе показывают, почему имени серии недостаточно

В таблице результатов проект устава называет новейшими публикациями WebDriver от 1 апреля 2026 года и WebDriver BiDi от 19 марта. К моменту подготовки этой статьи официальные страницы уже показывали более новые Working Drafts: WebDriver от 2 июля и WebDriver BiDi от 25 августа.

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

Одно имя охватывает и разные стадии зрелости. W3C по-прежнему публикует первую спецификацию WebDriver как Recommendation от 5 июня 2018 года и отдельно ведёт новый WebDriver Working Draft. Новый документ не наследует Recommendation-статус по совпадению названия. Старая Recommendation, в свою очередь, не описывает автоматически все команды и правила позднего проекта.

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

Snapshot и Draft выполняют разные функции

Процесс W3C предусматривает две формы публикации Candidate Recommendation. Snapshot требует подтверждённого запроса на переход или обновление и одновременно является Patent Review Draft, запускающим соответствующий период исключений. Публичное руководство W3C связывает Snapshot с консенсусом группы, публичной проверкой, формальными отзывами других групп и лицензионными обязательствами участников.

Candidate Recommendation Draft интегрирует предполагаемые изменения после Snapshot, чтобы сообщество видело и тестировало текущее направление. Упрощённые публикационные требования позволяют сохранять документ актуальным. Руководство W3C уточняет: такие изменения ещё не получили формального рассмотрения, а сам Draft не несёт патентной защиты, приписанной Snapshot.

Ни Snapshot, ни Draft не является стандартом W3C. Организация предупреждает, что Candidate Recommendation Snapshot может никогда им не стать. Этот статус сам по себе также не требует достаточного опыта реализации. В Living CR могут оставаться меняющиеся функции, неравномерная доступность, ограниченная совместимость или неполные тесты.

Это не обесценивает Snapshot. Напротив, точное название показывает, что установлено: проверенная цель реализации и патентная контрольная точка. Draft показывает интеграцию после неё. Recommendation добавляет одобрение W3C и ещё один порог доказательств реализации. Один ярлык не должен незаметно заимствовать свойства другого.

Соответствие существует только в соединённой записи

Проект устава уже содержит части доказательной дисциплины. Изменения в Candidate Recommendation и функции, присутствующие в развёрнутых реализациях, должны иметь Web Platform Tests. Новым возможностям нужны выражения интереса минимум от двух потенциальных разработчиков. Должны быть описаны безопасность, приватность и доступность, а горизонтальная проверка требуется на крупных переходах; первый запрос желательно направлять не менее чем за три месяца до входа в Candidate Recommendation.

Но ни один сигнал не создаёт полного операционного утверждения. Интерес ещё не работающий код. Наличие теста не доказывает полноту покрытия нормативного правила. Зелёный результат без commit тестов и сборки браузера нельзя воспроизвести. Функция за флагом отличается от функции в обычном выпуске. Клиентская библиотека также может ограничить или преобразовать доступную часть протокола.

Для существенных заявлений минимальный набор выглядит так:

неизменяемый Snapshot спецификации + тип зрелости + commit/выбор тестов + сборки браузера/драйвера/клиента + платформа + дата + исключения

Если проверялся Candidate Recommendation Draft, запись должна указывать предшествующий Snapshot и существенные изменения. Для Snapshot нужны решение о переходе или обновлении и патентное состояние. Политика, ссылающаяся на latest, должна сохранить механизм разрешения, время и полученную неизменяемую версию.

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

Задача не в принудительном переходе к Recommendation

Фразу из устава легко превратить в требование обязательно завершить Recommendation. Открытые источники не дают для него основания. W3C считает Living CR законным выбором. Для браузерной автоматизации непрерывно проверяемая цель может лучше соответствовать развитию через опыт реализаций, чем редкие финальные редакции.

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

Точный набор не останавливает живую модель. Он фиксирует свидетельство конкретного результата. Новые Snapshots, Drafts, тесты и сборки создают новые наборы, а различия остаются видимыми.

Что пока неизвестно

Advisory Committee может одобрить устав, потребовать правки или отклонить его. Положение о Living CR может измениться. WebDriver и WebDriver BiDi ещё не достигли описанной Candidate Recommendation, и дата первого перехода не названа.

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

Ограниченный вывод таков: если Candidate Recommendation становится постоянной точкой, точная идентичность версии входит в продукт управления. Имя серии объясняет, к какому проекту относится работа. Оно не сообщает, что именно работало.

Источники

  1. Объявление W3C о проекте устава Browser Testing and Tools
  2. Проект устава Browser Testing and Tools Working Group
  3. Действующий устав Browser Testing and Tools Working Group
  4. W3C Process Document
  5. Руководство по окончательной стадии зрелости
  6. Типы документов W3C
  7. Актуальный технический отчёт WebDriver
  8. История публикаций WebDriver
  9. Актуальный технический отчёт WebDriver BiDi
  10. История публикаций WebDriver BiDi
  11. Результаты WebDriver BiDi в Web Platform Tests
  12. Дерево тестов WebDriver BiDi в WPT