Summary

  • W3C's proposed Browser Testing and Tools charter says WebDriver and WebDriver BiDi should reach Candidate Recommendation with Snapshots, be updated continuously there and not deliberately advance to Recommendation.
  • That is a proposed operating model, not a completed charter decision. Both current technical reports remain Working Drafts, while the 2018 WebDriver Recommendation remains a separate published state.
  • W3C distinguishes a formally reviewed Candidate Recommendation Snapshot from a Candidate Recommendation Draft that integrates newer, not-yet-formally-reviewed changes. Neither may be cited as a W3C standard.
  • A reproducible support claim should join an immutable specification snapshot, maturity kind, test-suite commit and selection, browser/driver/client builds, platform, result date and known exclusions.

A long-term Candidate Recommendation is a policy choice

The Browser Testing and Tools Working Group standardizes the protocols that let an external process inspect and control a browser. WebDriver supplies the familiar command-and-response interface. WebDriver BiDi adds a bidirectional channel so events can flow from the browser to the controlling program. These are not merely documents read by standards specialists. Their algorithms are turned into browser code, driver code, automation libraries and tests that run continuously in development and production systems.

On 18 August 2026, W3C asked its Advisory Committee to review a successor charter for the group. Public comments remain open until 18 September, and the current charter has been extended to 23 October. The replacement is therefore still a proposal. Its significance lies in the operating policy it puts in plain language.

The group, it says, intends to publish the latest state of WebDriver and WebDriver BiDi as Candidate Recommendation, including Snapshots. It does not intend to advance the documents to Recommendation. Once Candidate Recommendation is reached, it expects to keep updating it. This is not an accidental backlog or a promise to finish later. It makes a continuing intermediate maturity state the planned destination.

W3C's own guidance explains why a group might do this. Candidate Recommendation can align more naturally with implementation work distributed across multiple codebases and their different prioritization systems. A group can publish reviewed Snapshots while continuing to integrate changes through Candidate Recommendation Drafts. The choice can keep the technical report near the code that supplies implementation experience.

But a living Candidate Recommendation changes the burden carried by a citation. Recommendation normally supplies a stable, W3C-endorsed reference with adequate implementation experience. If the series is designed to remain at Candidate Recommendation, “WebDriver,” “WebDriver BiDi” and even “the CR” are not precise enough for an audit, a procurement requirement or a bug report.

The charter's own dates show why series names are insufficient

The proposed charter lists a 1 April 2026 WebDriver publication and a 19 March 2026 WebDriver BiDi publication as the latest versions. By the reporting cutoff, W3C's live technical-report pages had moved. The latest WebDriver Working Draft is dated 2 July. WebDriver BiDi's is dated 25 August.

Nothing improper follows from that difference. A charter takes time to draft and review, while active technical reports keep changing. The embedded links continue to point into valid publication histories. The date gap is useful precisely because it exposes the nature of the authority: a charter authorizes a specification series. It does not freeze the bytes that an implementor, tester or operator used.

The same name can also carry more than one maturity state. W3C still lists the first WebDriver specification as a Recommendation dated 5 June 2018. It separately lists the newer WebDriver technical report as a Working Draft. The later document does not acquire Recommendation status by sharing the series name, and the older Recommendation does not automatically describe every command and behavior in the newer draft.

A mutable latest URL is convenient for reading. It is weak evidence for reproduction. Tomorrow it can resolve to different text while an old browser, driver or automation client continues to enforce yesterday's algorithms.

Snapshot and Draft are not interchangeable labels

W3C's Process divides Candidate Recommendation publication into two forms. A Candidate Recommendation Snapshot follows a verified transition or update request. It is also a Patent Review Draft, which triggers the relevant exclusion process. W3C's public guide says a Snapshot has Working Group consensus, public review and formal review from other W3C groups, together with royalty-free licensing commitments from participants.

A Candidate Recommendation Draft serves another purpose. It integrates intended changes after a Snapshot so the wider community can read and test the current direction. The Process minimizes the publication requirements so the specification can stay current. W3C's public document guide says those changes have not received formal review and that the Draft does not itself carry the patent protection described for a Snapshot.

Neither publication is a W3C standard. W3C explicitly warns that a Candidate Recommendation Snapshot may never become one. Nor does Snapshot status itself require adequate implementation experience. W3C's living-CR guidance says a Snapshot can still contain features that change, have limited interoperability, are unevenly available or lack tests.

These distinctions do not make a Snapshot untrustworthy. They tell the reader exactly what was established. A Snapshot is a reviewed implementation target and patent-review point. A Draft is a readable integration of later changes. A Recommendation adds W3C endorsement and a further implementation-evidence threshold. One label cannot silently borrow the properties of another.

Conformance lives in a joined record

The proposed charter already supplies several parts of a sound evidence discipline. Changes in Candidate Recommendation, and features already deployed, should have Web Platform Tests. New features should attract expressions of interest from at least two potential implementors. Security, privacy and accessibility implications should be documented. Horizontal review must be sought at major transitions, with review advised at least three months before first entry into Candidate Recommendation.

Those are valuable gates, but none produces a complete operational claim on its own. An expression of interest is not running code. A test file is not proof that it covers the normative requirement. A green dashboard result is not reproducible without the test revision and the browser build. A browser feature behind a flag is not the same state as a default release. An automation client can also transform or restrict the protocol surface it exposes.

For important claims, the minimum evidence tuple should contain:

immutable specification snapshot + maturity kind + test-suite commit + selected tests + browser build + driver build + client-library build + platform + result date + known exclusions

If the tested text is a Candidate Recommendation Draft, the record should name the preceding Snapshot and the substantive changes under test. If it is a Snapshot, it should link the transition or update decision and identify the patent-review state. A policy that follows “latest” should record the resolver, the resolution time and the immutable version obtained.

This tuple is deliberately narrower than a new certification regime. W3C decides publication status. The Working Group decides specification text. WPT contributors maintain tests. Browser and driver projects ship implementations. Automation-tool maintainers decide what their clients expose. An operator or buyer can preserve the join without claiming authority over any of those decisions.

The aim is not to force a Recommendation

It would be easy to turn the charter sentence into a complaint that WebDriver ought to reach Recommendation. The public evidence does not justify that conclusion. W3C itself describes living Candidate Recommendation as a legitimate choice. Browser automation develops through implementation feedback, and a continuously reviewable target may fit that reality better than infrequent final editions.

The governance risk is different. Downstream users will still ask whether a feature is “standard,” “supported” or “interoperable.” Without exact identities, a favorable result against one draft and one test selection can travel forward as a claim about the entire series. A later incompatible change can travel backward into an audit of an older deployment. The mutable name becomes a channel for maturity-state and version laundering.

An exact tuple lets the living model remain living. It does not freeze development. It freezes the evidence about a particular result. New Snapshots, Drafts, tests and implementations can produce new tuples. Differences become inspectable instead of being hidden under the same label.

What remains uncertain

The Advisory Committee may approve the charter, request changes or reject it. The living-CR clause may change before a final decision. WebDriver and WebDriver BiDi have not yet reached the Candidate Recommendation state described by the proposal. No date for their first CR transition is promised in the text.

The live WPT surface changes with test and browser updates. This Article does not grade current interoperability and does not infer support from a dashboard. It also does not claim that every downstream use needs the same evidence detail. A browser developer investigating today's failure may reasonably follow current main branches; a regulator or long-lived procurement contract will need an immutable reference.

The bounded conclusion is simpler: if Candidate Recommendation is the intended continuing endpoint, exact version identity becomes part of the governance product. A series name tells us where work belongs. It does not tell us what ran.

Sources

  1. W3C public-new-work announcement — proposed Browser Testing and Tools charter
  2. Proposed Browser Testing and Tools Working Group Charter
  3. Current Browser Testing and Tools Working Group Charter
  4. W3C Process Document
  5. W3C — Considerations on the final maturity stage of group deliverables
  6. W3C — Types of documents W3C publishes
  7. WebDriver latest technical report
  8. WebDriver publication history
  9. WebDriver BiDi latest technical report
  10. WebDriver BiDi publication history
  11. WebDriver BiDi Web Platform Tests results
  12. WebDriver BiDi WPT test tree