Summary

The green light came from implementers

In February 2017, four browser constituencies made a narrow but decisive call. Their public message in the W3C archive said the first WebAssembly API and binary format were ready to move beyond Browser Preview. The signatories did not call the work a completed W3C standard. They said no more useful design work was possible without implementation experience and substantial use. Browsers could turn it on by default. Future features would have to respect backward compatibility with that initial target.

That is a particular kind of authority. A committee can publish a draft; browser makers can make a format available to the people who load web pages. The 2017 agreement was powerful because it aligned separate executables on one initial target. It also created a constraint: once sites shipped modules against that target, later design improvements could not casually break the code already in circulation. The Community Group had made a practical bargain with future users.

The same message identified a JavaScript API, a binary format and a reference interpreter. It said the next step was to form a W3C Working Group and produce a specification for the initial version. There was already design text and a usable toolchain; “no W3C draft yet” does not mean “no written design.” The distinction is between a Community Group's implementation-ready MVP and a Recommendation completed through W3C's formal track.

The running code passed the paperwork

By 13 November 2017, Mozilla reported that Safari and Edge had joined Firefox and Chrome in shipping WebAssembly support. This is a statement about four browser products, not a measured claim that every device or every user had the feature. For a developer choosing a compilation target, however, four shipping browser families changed the calculation. The code could be served to real clients while the standards document was still climbing its own steps.

The 2017 W3C Working Group charter had forecast a first public draft in the fourth quarter of 2017 and a version-one Recommendation in the second quarter of 2018. The actual publication record puts the first public Core draft on 15 February 2018, a Candidate Recommendation snapshot on 18 July 2019 and the Recommendation on 5 December 2019. The timetable slipped. The charter and publication history do not identify a single cause for the slip, so the dates should not be turned into a tale of one obstructive meeting or one heroic vendor.

The stamp did a different job

W3C's December 2019 announcement covered three Recommendations, not merely a binary file description. The Core specification described the virtual machine and code format. The JavaScript Interface specified how JavaScript invokes WebAssembly functions and exchanges values. The Web API connected WebAssembly to fetching and executing resources on the web. Those boundaries mattered because a module that parses is not automatically a web application that loads, calls host functions and behaves consistently across browsers.

Formal review and a stable reference were not theatrical afterthoughts. The charter called for a test suite, implementation report, public technical discussion, cross-group review and W3C consensus procedures. W3C's 2019 news described the Recommendation as a portable, safe, low-level format with browser integration through JavaScript. The implementers had already carried a useful MVP into shipping products; the formal process specified the shared contract in a form others could inspect and implement.

The dates make a sharper point than either “standards lead” or “code leads” as a slogan. A Community Group and browser engineers locked down enough design to ship in 2017. The Working Group's first public draft followed in 2018. The Recommendation followed in 2019. One layer established deployed compatibility; another made its boundaries and obligations legible. Confusing the two either erases the running software or awards the formal stamp powers it did not exercise in 2017.