Commentary about browsers and the features they support is sometimes pejorative towards pre-standardisation features. Given Apple's constriction of Mozilla's revenue stream and its own strategic under-funding of WebKit, this usually takes the form "Chromium just ships whatever it wants."

This is true, of course, but not in the way commenters intend; and not only because Blink's rigorous launch process frequently prevents unvalidated designs from shipping.

Except for iOS, where Apple attempts to hide its role in undermining the competitive foundation of web standards, every vendor always ships "whatever it wants." That is the point of voluntary standards, and competition is the wind in those sails.

Working Groups don't gate what browsers ship, nor do they define what's useful or worthy. There are no seers; no Delphic oracles that fleetingly glimpse a true logos. Working Groups do not invent the future, nor do they hand down revealed truths like prophets of the House of Iamus.

In practice, they are thoughtful historians of recent design expeditions, critiquing, tweaking, then spreading the good news of proposals that already work through Web Standards ratified years after features first ship, serving to licence designs liberally to increase their spread.

In the end, this is the role of standards and the Working Groups that develop them: to license patents that read on existing designs, reducing risks to implementers who adopt them.

Anyone who tries to convince you otherwise, or invites you to try your hand at invention within a chartered Working Group, does not understand what those groups are designed to do. Sadly, this includes some folks who spend a lot of time in them.

Complaints about certain engines leading reveals a bias to fighting the last-war; fear of a return to the late 90s, when “irrational exuberance” applied not just to internet stocks, but also browser engines.

Unfounded optimism about our ability to deal with externalities of shipping prior to consensus created a great deal of pain. Misreadings of how browsers evolve in practice over-taught lessons that still invoke fear. But we have enough miles on the tires to see that standards aren't what create responsible feature development; thoughtful launch processes are.¹

As we will see, consensus is never a precondition for shipping, nor could it be. If it were, nothing would move forward, for it is the threat (and sometimes reality) of popular features shipping without a priori agreement that brings parties to the table. It's also the only reliable defence against the fifth column problem.

Terminology Traps

Before we get into the role of the charters that define Standards Development Organisation (SDO) Working Groups, we must define some terms:²

Proposal

Any design, in any sort of document (Specification, Explainer, or scrawl on the back of a napkin) offered inside an SDO for standardisation. Proposals are revised through collaborative processes which function best inside SDOs thanks to carve-outs in competition laws allowing competitors to collaborate in writing standards.

Proposals are implemented, and even shipped, well ahead of formal status as Web Standards in order to gain developer feedback, iterate on designs, and build confidence that they meet needs effectively.³

Specification

A document that describes the properties of an implementation, often in technical shorthand (e.g., Web IDL) and with reference to other specifications.

Specifications are by and for implementers, rather than working web developers, and are the documents to which the IPR commitments of Web Standards attach.

Explainer

An overview of a proposal. Explainers are not specifications, but encapsulate the key points of designs in terms of the problems they solve.⁴ The goal is to explain the why along with the what, in terms web developers can weigh.

In well-incubated designs, Explainers evolve in parallel to specifications. This forces API designers to think like web developers. Explainers serve as foci for considering alternatives and as well as “missing manuals” for early designs.

Web Standard

A specification that has been put forward by a chartered Working Group to the full membership, and granted official status after ratification. For example, by receiving the status as a Recommendation of the W3C by a vote of the Advisory Committee, or in the case of ECMA TC39, publication of an International Standard at ISO.

Web standards create clarity around IPR concerns which pre-standards specifications cannot. These commitments license the patents of parties participating in a Working Group under Royalty Free terms.

In practice, this also commits major firms to the defence of potential implementers, reducing risks across the ecosystem.

Standards Track

A specification document is "on the standards track" if its developers have signalled interest in formal, chartered Working Groups taking up their design for publication as a Web Standard, subject to clarification along the way. It is not necessary for any specific Working Group to agree for this description to hold.

Designs in this state often carry IPR grants, but provide less patent clarity ("contribution only") than official Web Standards.

Incubation

Any process outside a chartered Working Group in which web developers, browser vendors, and other interested parties meet to understand problems and design solutions. Drafts of incubated designs are often volatile. Eventually, if a problem is judged important by participants, one or more designs congeal into brief, high-level "Explainers".

Before features launch without flags in stable-channel browsers, developer and implementer feedback can lead to large changes in incubated designs. Designers and participants must actively solicit input and respond to substantive feedback constructively.

Proposals whose specifications receive formal status within SDOs are described as “adopted”, “recommended”, or “ratified”. This process binds the intellectual property of chartered Working Group participants to the licensing regime of the SDO by approval of the membership.

From this we can see that is nonsensical to discuss “proposals” and "standards" in the same breath. They are a binary pair. A specification has either one status or the other; it cannot be both.

No design that becomes a standard can start as anything but a proposal,⁵ and the liminal space of non-standard proposal is not somehow less-than or an aberration. Rather, it is an embryonic stage every design must pass through, and which every de jure Web Standard has taken at some point.

Armed with better language, we can develop an understanding of how features actually come to the web. Through this, we'll see why our optimism for standards has to come from our own powers of collaborative problem-solving, rather than waiting for designs to be handed down from Olympus.

Standardisation != Interoperability

Jake Archibald pointed out that linguistic precision is uncommon, and developers use the phrase “standard” or “web standard” loosely; a shorthand for features they can use without worry. That ground covers both official Web Standards and de facto standards. The example of WebP was raised, and was even more instructive than I recalled.⁶

A brief refresher: WebP was introduced by Google in 2010, shipping in Chromium in 2011. At that point, and for many years thereafter, WebP was not a standard. A high-level specification broke cover in 2012, but was not brought to an SDO. Patent rights and other IP questions were addressed only by Google's waiver and the Open Source licensing of libwebp.

Nearly all Chromium-based browsers adopted WebP by 2012. Microsoft Edge added support in 2018, Firefox joined the party in 2019, and Safari added support in 2020.

It was not until April 2021, a full decade after the format's introduction and after all major engines supported it, that WebP arrived at the IETF for standardisation. It finally earned RFC status in November 2024, four years after Apple unlocked wide compatibility, having been the last hold-out.

WebP gained tremendous adoption despite not being a standard for nearly 15 years. This has led some to suggest it was a Web Standard, as it had many of the properties expected of successful standards. Namely:

• Broad adoption. All major engines gained support before standardisation began in earnest.
• Stability. Despite adding opacity and animation later, every WebP image produced across the life of the format still renders correctly.
• Interoperability. The same WebP images work across implementations.
• IPR clarity. As the primary contributor to the format and reference implementation, Google's substantial legal and patent assets provided adopters with assurances related to the provenance of both the code and the codec fundamentals.

Many assume that Web Standards are the only path to achieving these attributes, but WebP shows us that this is mistaken. Web Standards deliver these properties most effectively and reliably, but WebP shows us that “being a standard” is not a requirement for interoperable implementation at scale, even in browsers.

Interoperability and adoption are, by inspection, independent of official status. Many formal Web Standards have spotty adoption or fail to achieve interoperability. The web also has a long history of de facto behaviours gaining official status long after interoperability and stability manifest in the market. This sits comfortably with the reality that every single web feature is non-standard for some fraction of its lifetime. At the limit, that fraction can be rather large.

Conflation of de facto standards, official Web Standards, wide deployment, and interoperability are likely to persist. However, those of us who work on browsers can and should be more precise, preferring “interoperability”, “widely deployed”, and “standards track” to “Web Standard” when those are more appropriate.

Standardisation != Responsibility

If we admit, as we must, that all features begin as non-standard proposals which proceed through official processes to become Web Standards, quality is never as simple as “standard good, non-standard bad.” A design can pass unaltered through every lifecycle stage without change to its technical shape or merits, and questions of wide implementation and interoperability are clearly extrinsic to the status of a design within an SDO.

We must locate definitions of relative goodness in more directly descriptive properties. I have given a few above, namely adoption, stability, interoperability, and IPR clarity. For a full account, we need to cover design-time attributes, including testability, specification rigour, wide review, and responsiveness to developer feedback . Taken together, they define what it means to solve important problems well on the standards track.

Developers and implementers weigh up these properties when judging APIs. Some designs, like WebP,⁷ can score highly on everything but adoption. WebP was not technically worse in 2015 than in 2019, or 2020, or 2024; only less widely adopted. Working web developers were free to exploit its benefits the whole time. Many did, and because it had been responsibly developed, interoperability followed, even before a proposal had been submitted to an internet standards body.

Likewise, we cannot judge other APIs shipped in a single engine to be low-quality on the basis of SDO status. Nor can we credit statements opposing them on that basis, particularly from parties that have not offered counterproposals. A single implementation may preclude features from becoming standards, but that says nothing about design fitness, or even prospects for eventual adoption.

This understanding draws our focus away from formal SDO status and toward more important properties of features. It also helps us weigh up the processes that gestate them:

• Are they friendly and open to developers, or are they smoke-filled rooms where old-timers hold sway?
• Do they encourage new work at the pace of emerging developer needs, or are they artificially constricted by a proliferation of veto players?
• Do those processes generate good tests and strong specifications, or do a few powerful editors regularly cut corners?
• Are features submitted for wide review to competent and responsive experts, or is Working Group "go fever" allowed to dominate?
• Do processes put evidence of solving end-user and developer problems⁸ ahead of groupthink and reckons?
• Do those processes allow high-quality features to ship ahead of full consensus, based on evidence?
• Do they adequately protect implementers from IPR risks?

These questions do not line up clearly with corporate jerseys. They do not favour one company's designs over another's. Google, Microsoft, Apple, and Mozilla all have fielded designs that easily pass these tests, and others that flunked. That's the thing about quality; metrics don't care about status or affiliation. Quality doesn't have a “team”, it has units of measure.

Quality tests help us evaluate features in the market-based ecosystem of voluntary standards. The presumed working mode of Web SDOs is that many ideas will be tried (responsibly, hopefully) and the best ideas should gain traction. Eventually, better designs sway the market, leading to calls for standardisation.⁹ Competitors who objected, even strenuously, can then adopt liberally-licensed designs, provide alternatives, or lose share. This logic does not designate grandees or smoke-filled rooms as arbiters of quality. Instead, we rely on voluntary adoption, the testable qualities of shipped designs, and developers voting with their feet.

Responsible, quality-oriented feature development processes reject priesthoods, seers, and oracles, putting evidence-based engineering in their place. This focuses us on solving problems we can see, showing our work, inviting critique, and engaging constructively.

There were never curtains from behind which a feature's essential “standardness” could be revealed, and we should not invent them because the messier, egalitarian reality of feature evolution seems disquieting. Like “Best Picture”, formal SDO status isn't a reliable indicator of quality. Each must judge for themselves.

In the end, the wider internet engineering community always decides if problems are relevant and if designs are “correct.”

There are no blinding flashes of insight, only the push and pull of competing proposals to solve user and developer needs. When standards fail to meet needs, developers patch over the gaps at great cost, or route around standards-based platforms altogether. It is no coincidence that the phases of the Blink Launch Process and tools like Origin Trials present practical steps away from Working Group mysticism. Moving, however haltingly, towards egalitarian, pluralistic collaboration has delivered tremendous progress, despite recalcitrant participants.¹⁰

What Working Groups Really Do

Along with other experienced colleagues at Google and Microsoft, I have had the privilege to teach the practice and theory of standards-track feature development to talented engineers working inside Chromium.

The role of chartered Working Groups looms large in those conversations, but it is far from central. This is because the primary job of a Working Group is to accelerate adoption of existing designs that have enough support to move forward and insulate them from IPR-based attacks. This is both their official job (per SDO process documents) and their primary value.

“I” dotting and “t” crossing is expected, and it can slightly alter designs, but chartered Working Groups never work well as venues for effectively canvassing developers for problems to solve. Nor are they good environments for testing ideas. If the goal is to solve new problems or design new solutions, chartered Working Groups are never the best forum for the simple reason that it is not what they are built to do.

Consider the most recent charters from a few lively W3C Working Groups:

• Web Apps (charter)
• Web Payments (charter)
• CSS (charter)
• Web GPU (charter)

Per the formal process governing charters, each group's convening document contains several sections that outline:

• A problem statement, laid out at the group's (re)charter.
• An explicit scope; i.e., technologies the group can consider in addressing that problem.
• An a priori list of documents and deliverables the WG will produce.

Everything in these charters works to provide clarity and precision about what the group will deliver because that is how members (firms, in the W3C's case) weigh up the costs and benefits of joining relative to their patent portfolios.

Yes, it's all about patents. Standards Development Organisations are, practically speaking, IPR clearing houses. From this perspective, all the hoops one must jump through to join a chartered group make sense:

• Q: Why do companies have to officially join each Working Group separately?

  A: Patents.

• Q: Why does each participant need to be approved by a company's main W3C delegate?

  A: Patents.

• Q: Why are there so many checkpoints in the process that appear to do little more than waste time?

  A: Patents.

• Q: Why does the whole membership need to vote to progress a document to a formal standard?

  A: Patents.

Features named in Working Group charters are the only designs a group can standardise, and groups run into trouble with lawyers when they exceed charter scopes, because participating firms may not have done a search in their portfolio (or their competitor's) regarding designs outside the pre-determined scope. When this happens, all progress can halt for an indeterminate amount of time. SDO processes and documents, therefore, work to cabin the risk, moving early design out of Working Groups and into other venues.

Chartered Working Groups Are Not Design Venues

All of this drives to a simple set of obvious conclusions: venues other than chartered Working Groups are necessary in order to do the sort of high-iteration-pace design work that leads to higher-quality designs.

It's a punchline that standards committees are bad at design, but this is by design. They do not have the cycles, mission, or tools needed to explore developer problems, let alone iterate towards compelling solutions. Their job, per the official process documents that convene them, is to ensure that certain quality attributes are tended to (e.g., tests and complete specifications) on the way towards licensing of the intellectual property embodied in specifications.

The Role of Incubation

To this end, internet SDOs have many alternatives that are better suited to design work, and which create glide paths for the fittest proposals into chartered Working Groups to gain eventual status as Web Standards. Here are a few:¹¹

• W3C

  • Interest Groups
  • Business Groups
  • Community Groups, particularly the WICG

• IETF

  • "Bar BOFs"
  • Official BOFs

• TC39

  • Stage 0/1 Drafts

It's always possible for designs to fail to solve important problems, or fail to solve them well, and better designs flow naturally from a higher pace of iteration and feedback. Incubation venues tend to work better for design because they lower some strictures Working Groups erect to create patent clarity. Instead of needing to pre-define their deliverables, these groups can fail fast and iterate. When they work, they can be submitted to Working Groups to get patent and IP issues finalised.

Incubation venues display very different working modes and membership than formal Working Groups. Instead of pre-decided, formal deliverables, groups can form around nebulous problem statements and define the issues long before landing on a single design. There is no stable set of delegates from member firms, largely dominated by implementers. Rather, interest groups may form organically, even from web developers interested in shared problems. Instead of predefined timelines and pre-ordained deliverables, these groups work at the speed of their need and understanding. And instead of design pivots representing potential failure, incubation venues can test multiple alternatives. Discarding entire designs is even healthy while the furious iteration of incubation plays out.

Lower barriers to entry for web developers, along with structures that encourage dynamic problem-solving coalitions, tend to create higher pace and more focused work. This, in turn, allows consideration of more alternatives and helps facilitate the iterations that hone design. Not every Incubation venue succeeds, and not every design they consider wins. But their outsized success vs. design-in-committee approaches has been apparent for more than a decade.

Only those mistakenly wedded to, or cynically selling, mystical notions of Working Groups as diviners of revealed truth try to rubbish the web's incubation venue's outstanding track record of delivery. Given the overwhelming success of incubation, including the demonstrated benefits of fail-fast iteration, we must then ask why there are still proponents of Working Group misuse and process opacity.

No Prophecies, Only Engineering

Splitting the needs of design from the strictures of standardisation isn't against the spirit of standardisation, nor is shipping ahead of a vote by the full membership of an SDO problematic. These approaches are written into the process documents of the internet's most effective bodies. Implementation experience is required for a proposal to become a ratified standard, and Working Groups are enjoined by process from undertaking the explorations incubation venues specialise in. Which is why those same SDOs build and encourage incubation groups.

This is an uncomfortable acknowledgement for some.

Folks I have talked to seem to imagine rooms filled with people who know everything and always make correct decisions. There are no such rooms. We're all just engineers trying to solve problems, from the heights of the TAG and the Internet Architecture Board to the scrappiest W3C Community Group or IETF Bar BOF. And sometimes we get it very wrong. But that should not immobilise us in fear; it should cause us to do what we always do when engineering: adopt processes and guardrails to improve quality and increase the rate of delivery.

Problems only get solved by people of good cheer working hard to spot them,¹² trying out solutions, and working collaboratively to document the ones that work best. There are no oracles in standards work, only engineers. And that's more than enough.

FOOTNOTES

1. While the Blink Launch Process raised the bar in some ways for every project, many parts of Blink's risk-based logic for feature leadership still lack analogues for tools like Origin Trials in other projects. Over the past decade, this has generally not been a major problem because other projects rarely lead (sadly). ⇐

2. And, it would seem, long-time browser engineers and standards participants. ⇐

3. The IETF famously phrases this principal as "rough consensus and running code", which indicates that that formal status as an official standard should be reserved for designs with experience in the market.

   A frustrating fraction of the web's erstwhile friends twist the arrow of causality, demanding formal standards status before they (or anyone else) dare to ship a proposal. This is, of course, entirely backwards, but sounds convincing to web developers who desire interoperability which comes from uniform implementation status which, historically, correlates with de jure status.

   This rhetorical bait-and-switch is deployed very frequently by fifth columnists. ⇐

4. Most contemporary web standards explainers use a template derived from a document I authored for use by Google's Web Standards engineers, and which was adopted by the W3C's Technical Architecture Group during my service there.

   The current template has drifted from the original somewhat, but the initial intent is in tact: to favour the perspective of working developers over implementers when weighing up potential designs.

   This explicit goal is realised through many steps of the Blink Launch Process. It's that process which forces Blink engineers to request TAG design review for new features. This combines with the reality that most new web features begin life within Chromium and Blink's “coalition of the willing”. As a result, designers of important new features experience Blink's process guardrails as the most constricting influence on quality as they work towards shipping. And one of those guardrails is to explain features in terms that web developers can understand via Explainers.

   As a sociotechnical system, the Blink Launch Process, and its integrations with the TAG and various incubation bodies, are calculated to act in a Popperian mode, rejecting claims to design authority and oracular Working Group pronouncements. In their place, we explicitly delegate power to groups that have done a good job of representing wider constituencies. The goal is to place the key question "does this design solve an important problem well?" at the centre of feature development, and to trust users (web developers) as judge of the results.

   We reject both essentialist and inductive intuitions about where features “should” come from, and instead require designers walk a mile in the shoes of their users. This is easiest to do in incubation venues like the WICG, where the barriers to bringing web developers into the conversation are lowest.

   This also is why the Blink API OWNERS expect “Considered Alternatives” sections of explainers to be exhaustive, and that examples appear the languages developers use (HTML, CSS, and JS), not the languages implementers think in (WebIDL and C++). Domain experts may understand the system, by sympathy for the machine is not a substitute for web developers trying designs and rendering their own judgement. The Blink Launch Process guards against go fever while enabling feature designers to launch responsibly, even when forced to go first by the disinterest of other vendors in solving problems. ⇐

5. Even if a proposal is, for some blighted reason, floated first within a chartered Working Group, it is still only that: a proposal without any standing as a standard. It is only upon publication of a formal standard document months or years later that a proposal, encoded in a specification, can be called a Web Standard and carry any of the attendant IP protections.

   That necessarily happens after the proposal has been offered, and generally happens months or years after all design work has completed and multiple interoperable implementations are fielded. ⇐

6. Until prompted to consider it, I had not been aware that WebP had made the transition to a formal standard in any venue. ⇐

7. It would, obviously, have been better for WebP to be floated at IETF many years prior, but adoption in every major engine occurred before that process began. ⇐

8. In that order, always. ⇐

9. In reality, new web features are a thinly traded market, and long experience (e.g., CSS's “prefixpocalypse") has taught the web community that uncontrolled experiments are disruptive and costly. This lesson has, in my view, been heavily over-sold.

   Responsible approaches (e.g., Origin Trials) now have a long track record of success. Those who argue that we must sort out differences in perspective exclusively by thinking hard about designs within the teleconferences of chartered Working Groups have not demonstrated that their approach is superior in any way that I can see. Simply trying ideas and gathering developer feedback has, despite tremendous resistance from Apple, generated a many important and high-quality features over the past decade using this model.

   Had we waited for Working Groups to recover from stupors induced by fifth columnist's disinterest, the quality of the resulting designs would not have improved substantially. Nor, in my estimation, would they be more likely to eventually achieve status as ratified and widely adopted Web Standards.

   There will always be a role for chartered Working Groups to improve on extant designs, but we have falsified the thesis that it is necessary for design to happen within them. The positive qualities of successful features are not down to venue, but the constituencies involved, and the evidence used to evolve them. That developer involvement and vendor flexibility towards feedback overlapped with Working Group-centered design efforts at certain moments in the past gives rise to much confusion. New entrants, thankfully, can skip old muddles and move straight to beginning their work in more entrepreneurial, high-iteration-rate venues built for incubation. ⇐

10. Many big, old chartered Working Groups attract participants who are earnestly confused about the value of their own contributions or the correct scope of the group's activities. Luckily, it is not necessary to convince them that they should not have outsized power in these domains. Instead, we only need to route around by moving early design work to incubation venues that enable more productive and egalitarian practices.

    There is little that hard-done-by WG delegates can do when this happens, other than to muddy the waters about what the best order of operations is. They cannot prevent design work from decamping to more fertile ground because it is in full alignment with the roles assigned to Working Groups and their feeder venues by the formal processes that govern SDOs.

    Design work should never have been on their docket, and it is always illegitimate Working Groups to attempt to monopolise it. Their charters make this extremely clear. ⇐

11. The WHATWG is unique among internet SDOs in disavowing any sort of incubation or early design process, which largely serves to make the W3C's various appendages (particularly the WICG) more useful and vibrant. ⇐

12. Taking developers seriously and not being dismissive about the needs they express is the first step in this work. It is therefore extremely problematic when implementers gaslight developers or claim the needs they are taking time to express are somehow illegitimate.

    There are many cases where an SDO or Working Group can't, or shouldn't, work to solve certain problems. But we can engage those questions without being dismissive, and should show our work along the way. Vendors who make a habit of brushing off developers, therefore, bring disrepute to the whole goal of standards work. ⇐