Summary

  • W3C’s operative 2025 Process lets a Recommendation add new features through its existing document only when it opted in before first publication. The 25 October 2026 draft would lift that restriction for every Recommendation.
  • A proposed feature would still face a public Last Call of at least 60 days, Advisory Committee review, a patent exclusion opportunity and implementation evidence before it enters normative text. The practical change is where the default feature-set guarantee sits: a dated version keeps its identity; an undated latest-version link cannot carry that guarantee by itself.

The same address, a bigger house

Someone putting a W3C Recommendation into a contract can paste a link and get on with the day. That link is doing more work than it seems. Is it the date-stamped edition that the parties examined, or a pointer to whichever edition W3C publishes next? The difference is easy to ignore when the next edition fixes a typo. It becomes expensive when the permitted feature set grows.

The operative 18 August 2025 Process draws a deliberate line. A Recommendation may be revised for editorial or substantive issues. To add a genuinely new feature to the existing Recommendation, however, the document must already have identified itself as allowing new features before its first Recommendation publication. If it did not, the Working Group can build a new technical report, beginning at First Public Working Draft, and take that through the normal track. The old document can be maintained; its default feature set does not quietly expand through an update.

The 25 October 2026 Process draft proposes to erase that division. Its section on substantive revisions lets tentative class 3 changes and class 4 new features appear as candidate amendments in any Recommendation. The text says the former restriction has been lifted “for simplicity.” That phrase is doing a spectacular amount of lifting. The change removes a choice that had to be declared at the point when a Recommendation first became a standard. Under the proposed rule, every Recommendation begins with a route to later features.

The proposal is a Draft Community Group Report in the next Process cycle. W3C’s status section says its 2025 Process remains operative while the Advisory Board prepares the draft for Advisory Committee review. A merged edit to a draft rulebook is a real editorial decision; it has not yet rewritten the rule for every live standard.

A promise small enough to hide in a link

The W3C Process pull request states the trade plainly. Its author explains that, absent an explicit opt-in, the feature set of a Recommendation could not change under the old rule even while editorial work and bug fixes continued. That gave a reader of the undated Recommendation URL confidence about scope. The author says the distinction caused confusion and that the group found scant evidence of anyone relying on the guarantee. The pull request merged into the draft branch on 22 July 2026, retiring eight defined terms and cutting a net 43 lines outside its retired-terms appendix.

The “scant evidence” observation is a reason given in a Process change, not a census of procurement contracts, policies or software implementations. The public pull request offers no denominator for that wider reliance. The distinction matters because silent reliance leaves few comments in a standards repository. People cite a stable-looking link in a requirements document and discover the ambiguity only when two parties try to enforce different editions of it.

W3C’s own guide to referring to standards supplies the immediate remedy. A “this version” URI identifies a specific publication. A “latest published version” URI follows the document series, and an Editor’s Draft points to current work that may not have Working Group review. W3C says it tries to keep each “this version” publication available in its original form, apart from limited corrections to broken markup or links. Under the proposed Process, anyone who needs a fixed feature set should name the dated edition. A bare latest-version URL becomes a decision to follow later approved revisions, including potential additions.

This is where the governance story lives. W3C can offer a sound amendment procedure and still leave a contract writer with a bad reference. The standards body controls the publication path. The adopter controls which edition becomes binding in its own system. Calling both of those acts “following the standard” buries the actual handoff of authority.

The amendment is not a trapdoor

A Working Group could not simply slip a new API into a Recommendation overnight under the draft. A candidate amendment is an annotation; it does not yet change normative requirements. To fold it into the standard, the group must seek a Last Call for Review of Proposed Amendments, give at least 60 days for comments, solicit implementation experience, go through Advisory Committee review and a patent exclusion opportunity, address comments, demonstrate adequate implementation experience and request an updated Recommendation. The group can also take a Working Draft or Candidate Recommendation route.

The public 26 October ARIA meeting minutes show why those steps matter to people doing the work. Editors discussed evergreen amendments, review timing, patent windows, change logs and the problem of horizontal review arriving late after implementers have started. Those minutes record a process discussion, rather than a new ARIA feature or adoption of the Process draft. They put a human voice next to the rulebook: a reviewer needs to understand the change before an implementation hardens around it.

The old restriction offered a separate kind of protection. It forced a new-feature decision to declare itself through a new report when the original Recommendation had not opted in. The draft substitutes a common amendment route for that special starting condition. Review remains, but the signal to a casual user of the undated URL changes. W3C can simplify its vocabulary; downstream users will have to become more exact about version identity.

Sources