The goal of the WHATWG’s Living Standards is to achieve interoperable implementations. With an ever-evolving web platform, we want changes to our standards to reach all implementations quickly and reliably, but from time to time there have been mishaps:
- Two table-related interfaces were ignored by implementers for a decade, but when finally removed from the standard it turned out that WebKit had just added them. Sorry!
- In 2007, the serialization algorithm for <pre> was changed to add an extra newline, so that it would roundtrip correctly. It was implemented in Presto (Opera) in 2012 (and the standard was tweaked), then implemented in Gecko in 2016, but they found it was not web compatible, so it was reverted. Oh well.
- We changed how non-empty URL attributes are reflected with support from two implementers, but nobody followed through with the change and it was later reverted. Ahem.
Three months ago, we changed the process for the HTML Standard to encourage writing tests and filing browser bugs for normative changes. (Normative means that implementations are affected.) This was the first step on a path towards improving interoperability and shortening the feedback cycle, and it has thus far exceeded our own expectations:
- “Tests and bugs speed up the turnaround time a lot. Without this it could go years before a browser vendor picked up or objected to a change (even if someone from that browser had given an a-OK for the change). Now some changes have patches in browsers before the change has landed in the spec.”
- “Writing tests also increases the quality of the spec, since problems become clear in the tests. It also seems reasonable to assume that the tests help getting interoperable implementations, which is the goal of the spec.”
- “I feel much more sure that when I make a spec change, I am doing all I can to get it implemented everywhere, in precisely the manner I intended.”
As an example, see Remove "compatibility caseless" matching where 3 of the 4 browser bugs are now fixed, or Add <script nomodule> to prevent script evaluation where all vendors have indicated support, and WebKit has a patch to implement the proposed feature and are contributing their tests to web-platform-tests—even before the standard’s pull request has landed.
Note in particular that this has not amounted to WHATWG maintainers writing all new tests. Rather, we are a community of maintainers, implementers and other contributors, where tests can be written to investigate current behavior before even discussing a change to the standard, or where the most eager implementer writes tests alongside the implementation.
We have been using this process successfully for other WHATWG standards too, such as Fetch, URL, and Streams. And today, we are elevating this process to all WHATWG standards, as now documented in the WHATWG contributor guidelines.