Summary

  • W3C approved the Web Performance Working Group’s new charter on 10 August 2026; it runs through 1 August 2028.
  • The final text says new features should have expressions of interest from at least two implementors before entering specifications maintained as Candidate Recommendations.
  • A feature without two expressions of interest may still appear in a Candidate Recommendation draft, but it must be marked at risk.
  • Advancement beyond Candidate Recommendation expects two independent interoperable implementations per feature, verified through open tests, while the W3C Process retains a documented exception path.
  • A feature evidence-state receipt should therefore record interest, adoption, at-risk status, implementation identity, test revision and transition decision as separate claims.

The word that changed

The Web Performance Working Group measures the behaviour people feel but rarely see directly: loading, rendering, responsiveness, interaction latency, memory and related aspects of application performance. Its new charter was approved on 10 August, after a public proposal and Advisory Committee review, and gives the group authority through 1 August 2028.

One change between the June proposal and the approved text deserves attention beyond this group. The final success criteria say that all new features should have “expressions of interest” from at least two implementors before being incorporated into specifications maintained as Candidate Recommendations. The proposed text had spoken in terms of implementer support. The final phrase is narrower and more honest about what the evidence proves.

Interest can mean that an implementor sees a problem worth exploring, intends to review drafts, is willing to prototype, or wants an option preserved while product choices remain open. It does not necessarily mean that a feature has an engineering team, a shipping date, complete tests or a durable commitment. Treating those states as equivalent would turn a useful early signal into an implementation claim it cannot bear.

The charter itself protects the distinction by setting another threshold later. To advance beyond Candidate Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature, with interoperability verified through open test suites. It also says every feature needs an open test suite. The first threshold asks whether more than one implementor has reason to consider a feature. The later threshold asks whether independent systems actually behave compatibly under observable tests.

Those are not weak and strong versions of the same vote. They are different kinds of evidence.

Four states, not one support label

The charter exposes at least four states through which a feature can pass.

First is incubation. A proposal can develop in the Web Platform Incubator Community Group, where ideas, use cases and early implementations can be tested without pretending that the Web Performance Working Group has adopted them.

Second is Working Group adoption. The coordination section says that a WICG proposal implemented and available in at least one major browser, with support from one more, may be adopted by the Web Performance Working Group. Adoption changes the institutional home and makes formal standards work possible. It does not mean the proposal has passed the later interoperability test.

Third is inclusion in a Candidate Recommendation draft. The charter permits a new feature without two expressions of interest to be incorporated into such a draft only if its at-risk status is annotated. That is a deliberately conditional state. The feature is visible for review and implementation experience, but its survival is not promised.

Fourth is evidence for advancement beyond Candidate Recommendation: implementation of each feature, independence, interoperability and an open test suite. The W3C Process describes Candidate Recommendation as the stage for collecting that experience. A Candidate Recommendation Draft can carry intended changes for review; a Candidate Recommendation Snapshot has a different process and patent role. Neither title should be flattened into “standardized and supported.”

This sequence explains why a single support column is inadequate. A green mark might refer to an interested organization, an experimental build, a browser implementation behind a flag, a Working Group adoption decision, a passing subset of tests or a completed independent implementation. Each is useful. None authorizes the reader to infer all the others.

Mozilla’s response demonstrates the boundary

Mozilla’s public charter-review response is a useful example precisely because it is supportive. The organization said it supported the proposal whether or not its suggested changes were adopted. It backed changes to the wording about support from at least two implementers. It also indicated an intention to review drafts, develop experimental implementations and send experience reports, and develop products based on the work.

The public implementation-schedule field was left blank.

That does not weaken the response. It defines it. The statement supplies evidence that an important implementor sees value in the group’s work and expects to engage. It is not a feature-by-feature list, does not name two implementors for any one feature, and does not promise a date on which a particular API will ship. A careful public record should preserve that scope instead of upgrading broad organizational intent into a deployment commitment.

The same rule applies to participation. The group page lists organizations and contributors, but membership is not support for every deliverable. Attendance can expose expertise, opposition and implementation constraints. It cannot be used as a silent proxy for a product decision.

At risk is a status, not a verdict

The at-risk annotation is equally easy to misread. In ordinary language, “at risk” sounds like a prediction of failure. In W3C process, it can perform a narrower job: warn reviewers and implementors that a feature may be removed during a later transition without requiring the same return path as an unmarked substantive change.

The WebPerf charter uses that tool to keep exploratory movement possible. A feature with fewer than two expressions of interest may enter a Candidate Recommendation draft, but the condition must travel with it. That is not rejection. It is also not a promise that the surrounding document’s maturity belongs to the feature.

The annotation must therefore remain attached to an exact feature and document revision. If the label disappears, a reader should be able to learn whether a second expression of interest arrived, the feature was removed, the wording changed, or an editor simply reorganized the specification. A current page without history cannot answer those questions.

There is a second reason to keep exact versions. The charter directs testing through Web Platform Tests and calls for open suites. Test results are meaningful only against a test revision, implementation version and specification state. “Two browsers pass” can conceal different feature flags, partial coverage, common code ancestry or results obtained against different drafts. Independence is a property that needs a reason, not just a count.

The rule has an exception—and should show it

The charter says two independent interoperable implementations are expected. The W3C Process asks for adequate implementation experience but allows the Team, in a compelling case, to approve advancement with minimal experience. It requires the exception and its rationale to be made public.

That path matters because a governance record should not make an expectation look absolute and then hide the cases that do not fit. An exception is not evidence that the ordinary criterion is meaningless. It is a different decision entity: who decided, under which Process version, for what feature or specification, on what evidence, and with what public explanation.

A transparent exception can be more accountable than a nominal two-implementation count assembled from weakly independent code. Conversely, an unexplained deviation can make the success criterion decorative. The correct record preserves the ordinary evidence and the competent exception rather than using either to erase the other.

This is where Heng Lu’s distinction between publication and adoption is useful but must be applied carefully. Implementations, validation and actual use discipline institutional language because they reveal whether independently operated systems can work together. They do not, by themselves, create W3C Recommendation status. The institution decides its publication state; running systems supply evidence about operational reality. A trustworthy record shows both authorities without letting either impersonate the other.

A feature evidence-state receipt

W3C already publishes charters, specifications, issues, test repositories, group decisions and implementation material. The missing entity is a small join between them. For each new or materially changed feature, a public evidence-state receipt could record:

  • an immutable feature identifier and specification revision;
  • the charter and Process version governing the decision;
  • each public expression of interest, naming its implementor, date, scope and source;
  • whether the statement is exploratory, scheduled, implemented, withdrawn or silent on timing;
  • the Working Group adoption decision and the proposal revision adopted;
  • the URI and history of any at-risk annotation;
  • each implementation’s product, engine and version, plus the reason it counts as independent;
  • the open test-suite revision, feature coverage and dated results;
  • the maturity transition, objections and any published Process exception; and
  • the next review, correction and supersession state.

The record need not expose confidential product roadmaps, proprietary code or security-sensitive infrastructure. It should not force an implementor to turn an expression of interest into a promise. Its purpose is the opposite: to prevent a narrow public statement from being reused as a broader claim.

The approved charter has already done the important conceptual work. It says interest can justify attention, conditional inclusion can remain visibly at risk, and interoperability requires different evidence. The next step is to make those distinctions survive contact with dashboards, press releases, procurement requirements and the shorthand of “browser support.”

Sources

  1. W3C — Call for Participation after approval of the Web Performance Working Group charter
  2. W3C — approved Web Performance Working Group Charter
  3. W3C — diff between the proposed and approved charters
  4. W3C — public notice of the proposed charter review
  5. W3C public review archive — Mozilla’s charter response
  6. W3C — Process Document
  7. W3C — Web Performance Working Group publications
  8. W3C — Web Performance Working Group page
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption