The standards body story — IETF, W3C, WHATWG
Every running protocol on the internet is governed by some institution that decides what is and is not the protocol. The institutions are not famous; their proceedings are dry; their politics are visible only to participants and the small community of journalists who cover infrastructure. They are nevertheless among the most consequential institutions of the contemporary world, because they decide what the web is allowed to do, what features it must support, who is allowed to add new ones, and what counts as a legitimate disagreement. The web’s standards have been governed, at different times and in different combinations, by the Internet Engineering Task Force, the World Wide Web Consortium, the Web Hypertext Application Technology Working Group, and ECMA International, with various ad-hoc arrangements among them. The history of those institutions and their interactions is the history of how the web has been governed at the technical layer, and the history is messier than the institutional self-descriptions usually suggest. This chapter is about that history: how it produced the web’s current standards, who has been driving the decisions, where the conflicts have come from, and what has been won and lost in the institutional politics.
The IETF tradition
The Internet Engineering Task Force was formalized in 1986, but its working method had been in place at the various ARPA-funded standards groups for the previous fifteen years. The method was: anyone could participate, anyone could submit a draft, drafts were discussed in working groups, and a draft became a standard when there was “rough consensus” among the working group and “running code” demonstrated that the draft was implementable. David Clark, the MIT engineer who was one of the IETF’s most influential figures, summarized the method in a 1992 talk: “We reject: kings, presidents and voting. We believe in: rough consensus and running code.” The slogan stuck.
The IETF’s working method was, by the standards of formal standards bodies, almost anarchic. There was no membership. Anyone could come to a meeting; the meetings were three times a year, in various cities around the world. Working groups operated mostly through mailing lists, and the lists were open subscriptions. The decisions were made by the chairs and area directors based on their assessment of the discussion, with no formal voting and no quota system. The Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG) provided light oversight. The whole apparatus depended on the participation of competent volunteers — engineers from various companies and universities who showed up to the meetings, did the work, and produced the specifications.
The method had limitations and the limitations were known. Rough consensus could be hard to determine and rough consensus on contentious topics could exclude perspectives that were not represented in the working group’s volunteer pool. The working groups tended to be dominated by people who had time to attend the meetings and follow the mailing lists, which skewed the demographics in predictable ways. The “running code” requirement biased the process toward implementations that already existed, which sometimes meant that the standards followed market-driven decisions made elsewhere. But the method worked, in the sense that it produced specifications that interoperated and that the actual protocol implementations broadly conformed to. The IETF’s RFCs (Requests for Comments) are the closest thing the internet has to authoritative documentation, and the standardization process that produced them is the closest thing the internet has to a constitutional system.
The IETF produced the foundational web standards: HTTP/1.0 in RFC 1945 in 1996, HTTP/1.1 in RFC 2068 (1997) and RFC 2616 (1999, revised through RFC 7230 in 2014 and RFC 9110 in 2022), and the URI specification in RFC 3986 (2005). The HTTP standardization in particular was a substantial effort, with Roy Fielding and Henrik Frystyk Nielsen as principal editors, and with substantial input from the major browser and server companies. HTTP/1.1, in particular, was a real protocol — pipelining, persistent connections, content negotiation, chunked transfer, conditional requests — that was used at internet scale for over fifteen years before HTTP/2 began to displace it.
The W3C
The HTML side of the web was a different story. HTML was not, originally, an IETF standard; it was a CERN-produced specification that grew through informal extension as Mosaic and the early browsers added features. The IETF began an HTML working group in 1994 that produced HTML 2.0 (RFC 1866 in 1995), but it became clear that HTML’s evolution was happening too fast for the IETF process to keep up with, and that the political dynamics among the browser vendors were not suited to the IETF’s volunteer-driven model. A different institution was needed.
The institution that emerged was the World Wide Web Consortium, founded in October 1994 at MIT, with Tim Berners-Lee as director. Berners-Lee had moved from CERN to MIT specifically to start the W3C; CERN, as a physics laboratory, was not the appropriate institutional home for a long-term standards body for the web. The W3C was structured as a membership organization. Companies and other institutions paid membership dues; in exchange they got the right to participate in working groups, vote on recommendations, and influence the W3C’s direction. The dues were substantial — the highest membership tier (for large companies) cost tens of thousands of dollars per year — and the membership was, in consequence, dominated by companies that had a commercial stake in web standards.
The W3C produced “Recommendations” rather than “Standards.” The terminological choice was deliberate: the W3C had no power to compel anyone to implement its specifications, and the term “Recommendation” was meant to acknowledge that compliance was voluntary. In practice, the major browsers implemented the W3C Recommendations (mostly), and the Recommendations functioned as standards in the working sense.
The W3C’s working method differed from the IETF’s. The IETF’s “rough consensus and running code” became, at the W3C, a more deliberate process of working drafts, candidate recommendations, proposed recommendations, and final recommendations, with formal review periods and member voting. The pace was slower. The IETF could turn around a specification in months; the W3C often took years. The slowness was sometimes a feature (it produced more carefully-thought-out specifications) and sometimes a bug (it left the browsers to invent features that the W3C process could not keep up with). The browser companies, particularly during the late 1990s, frequently shipped features before the W3C had specified them, and the W3C then had to retrofit specifications to match what the browsers had done.
The XHTML 2.0 failure
The W3C’s most-celebrated failure was XHTML 2.0. After producing HTML 4.01 in 1999 and XHTML 1.0 in 2000 (a reformulation of HTML 4 in XML syntax), the W3C’s HTML Working Group turned its attention to XHTML 2.0, which was to be a clean-slate redesign of HTML. XHTML 2.0 would drop legacy features, require strict XML conformance, introduce a uniform link mechanism, restructure the form model, and generally bring HTML closer to the kind of semantic-web vision Berners-Lee had been articulating. The work proceeded through the early 2000s. The browser vendors, watching, became increasingly unhappy.
The browser vendors’ objection was practical. XHTML 2.0 was not backwards-compatible with the HTML that was actually deployed. Implementing XHTML 2.0 would require the browsers to support two parallel parsing engines — one for the legacy HTML in the wild, one for the new XHTML 2.0 — and would require web authors to choose between the two. The W3C’s working group was, the browser vendors believed, designing for a hypothetical future in which authors would migrate to the new format, ignoring the fact that authors had not migrated to XHTML 1.0 in the years since it had been recommended. The web in 2004 was overwhelmingly HTML 4 with the various extensions the browsers had added; XHTML 2.0 was a plan to start over, and the browser vendors did not want to start over.
In June 2004, three browser vendors — Apple, Mozilla, and Opera — published a joint statement announcing the formation of the Web Hypertext Application Technology Working Group (WHATWG) as an alternative to the W3C’s HTML standardization effort. WHATWG would produce specifications for HTML and related technologies that took the existing web as the starting point, that specified what browsers actually did, and that evolved compatibly with the deployed base. The W3C continued its XHTML 2.0 work for several more years before formally abandoning it in 2009.
The WHATWG revolt was, in retrospect, a turning point in the institutional history of web standards. The browser vendors had effectively declared that they would standardize the web’s central technologies themselves, with or without the W3C’s involvement. The W3C, after some initial conflict, accepted the situation and began collaborating with WHATWG on what became HTML5. HTML5 was a specification of the existing web — what browsers actually did, what authors actually wrote — with extensions for new features (canvas, video, audio, web storage, web workers, etc.) that were already being implemented or planned by browser vendors. HTML5 was published as a W3C Recommendation in 2014, but the specification continued to be developed jointly with WHATWG, and the relationship between the two organizations remained complex through the 2010s.
The 2019 agreement
In May 2019, the W3C and WHATWG signed a formal Memorandum of Understanding. The MoU resolved the long-standing tension by accepting WHATWG’s “Living Standard” model — in which the specification is continuously updated rather than versioned — as the canonical specification for HTML and the DOM, with the W3C deriving its Recommendations from WHATWG’s living standard. The agreement was, effectively, the W3C’s acknowledgment that WHATWG had won the substantive argument: the web’s central technologies would be specified by the browser vendors, working in the WHATWG process, with the W3C playing a coordinating role for adjacent technologies and for the formal Recommendation track that some industries and governments require.
The implications of this arrangement are worth being specific about. The HTML and DOM standards are now produced by an institution (WHATWG) whose membership is, effectively, the major browser vendors: Apple, Google, Mozilla, and Microsoft. The WHATWG’s working method is open in the sense that anyone can read the specifications and submit issues, but the decisions are made by the browser vendor representatives, with limited representation from authors, users, or independent technical experts. The W3C, which had been the formal venue for broader participation in web standards, is now a coordinating body for adjacent technologies (accessibility, internationalization, semantic-web, RDF, CSS — CSS continues to be a W3C standard) rather than the primary venue for the web’s central technologies.
This is not, on balance, a bad outcome. The browsers are where the web actually lives; the browser vendors have the technical expertise and the institutional resources to produce serious specifications; the WHATWG’s living-standard model is more responsive to the web’s actual evolution than the W3C’s slow Recommendation process had been. But the shift is a real one, and it should be named: the web’s central standards are now produced by a vendor consortium with limited external accountability, rather than by a broader institutional process. The trade-off is responsiveness for participation.
ECMA and JavaScript
JavaScript’s standardization has been a separate institutional story. JavaScript was created at Netscape in 1995, as the previous chapter described, and was submitted by Netscape to ECMA International — a European standards body originally founded as the European Computer Manufacturers Association in 1961 — for standardization in 1996. ECMA’s Technical Committee 39 (TC39) was given responsibility for the language. The first edition of ECMAScript (the standard’s official name) was published in 1997; subsequent editions have followed at varying pace.
TC39 has produced JavaScript’s evolution through a careful and increasingly successful process. The committee includes representatives from the browser vendors, from companies that use JavaScript heavily, and from various other interested parties. The process for adding features to the language uses a “stage process” in which proposed features advance through stages of consideration, with each stage requiring more substantial evidence of design and implementation feasibility before the feature can become part of the language. The process is slow by the standards of feature-addition in other languages but fast by the standards of formal standards bodies, and it has produced a language that has evolved substantially while maintaining backward compatibility with the JavaScript of 1996.
The TC39 process is, by reputation, one of the better-functioning standards processes in modern computing. The browser vendors take it seriously; new features that pass TC39’s stages get implemented in browsers within a reasonable time; the language’s evolution has been broadly coherent rather than fragmentary. The cost has been the language itself, which has grown enormously and now contains many features and many ways to do similar things, with the various features representing different generations of TC39’s preferred styles. The success of the process has also been the cause of the language’s bloat.
ECMA’s other relevant standards include ECMA-262 for the core JavaScript language, ECMA-402 for internationalization, and various other JavaScript-adjacent specifications. The W3C, WHATWG, and TC39 collaborate on the various web APIs that bridge JavaScript and the DOM, with the WHATWG handling the DOM, the W3C handling many of the broader APIs, and TC39 handling the JavaScript language itself. The boundaries are sometimes contested but are largely workable.
The EME controversy
The standards-body story has had its share of substantive controversies. The most prominent in recent years was the W3C’s standardization of Encrypted Media Extensions (EME), which provides a JavaScript API for digital rights management systems in the browser. EME does not itself contain DRM; it provides a hook by which DRM modules can be invoked. The DRM modules are proprietary, supplied by various companies (Widevine from Google, FairPlay from Apple, PlayReady from Microsoft), and they are the actual mechanism by which media providers (Netflix, Spotify, etc.) restrict how their content can be used.
The case for EME was that DRM was going to exist on the web one way or another. Media providers required it; browsers were already implementing it through proprietary plugins (Flash, Silverlight); the plugins were a security and stability disaster; a standardized API would let browsers implement DRM in a controlled way that did not require proprietary plugins. The case against EME was that DRM was, in many participants’ view, an inappropriate technology to standardize. DRM restricts what users can do with content they have legitimate access to; it requires non-free code in the browser; it interferes with accessibility, with archiving, with security research, with the basic principles of an open web. The Free Software Foundation, the Electronic Frontier Foundation, and many individual web standards participants opposed EME on these grounds.
The W3C standardized EME anyway, in 2017, after a multi-year debate. Cory Doctorow, a writer and activist who had been a participant in the standards process through the EFF, resigned from the W3C in protest. The standardization passed by a vote of the W3C membership, with the support of the major browser vendors and the media companies, and against the opposition of various civil-society organizations and individual participants.
The EME case is worth dwelling on because it shows the limits of the standards-body model. The W3C is, formally, a consortium that produces specifications by consensus among its members. In practice, the members are mostly companies, and the companies’ interests are mostly commercial. When commercial interests align around a standard that is bad for users or for the broader web (as the EME opposition argued was the case), the standards process produces the standard. The civil-society organizations that participate in the W3C are outnumbered and out-resourced. The IETF’s traditional bias toward “rough consensus” rather than majority voting was, in the W3C, replaced by formal membership voting in which corporate members had the deciding say.
The corporate dominance pattern
EME was an unusually visible case of a broader pattern. The web’s standards are made by a small number of large companies — primarily Google, Apple, Microsoft, and (with declining influence) Mozilla — with various smaller companies and civil-society organizations participating at the margins. The W3C’s membership rolls include hundreds of organizations, but the active participants in the working groups that actually produce specifications are dominated by the browser vendors. The WHATWG is, structurally, a browser-vendor consortium. ECMA’s TC39 is, in practice, browser-vendor-dominated.
The dominance is not, in many cases, malign. The browser vendors have legitimate technical expertise; they have the implementation experience that other parties lack; they have to live with the consequences of the standards in ways that less-implementing participants do not. There is a real argument that the people writing the standards should be the people writing the code, and that the browser vendors are accordingly the appropriate body. The argument has force.
The argument also has costs. Standards produced by a small group of large companies tend to reflect the interests of those companies, even when the participants are trying to act in the broader web’s interest. Features that benefit browser vendors get implemented; features that benefit smaller players or alternative use cases sometimes do not. Privacy features that limit advertising tracking have been contested, sometimes for years, with the various commercial interests of the participants visible in the contests. Web payments, identity, authentication — each of these standards has been shaped by the commercial interests of the participants, and the shape sometimes shows.
The standards-body story is not a story of villains. It is a story of how technical decisions get made in a world where the institutions that make them have to be funded and the funding mostly comes from the parties whose technical interests are being decided. The same pattern plays out in many other technical-standards contexts; the web is not unique. But the pattern has consequences for what the web becomes, and those consequences are part of the broader story of how the web has evolved away from its original design.
What has been lost in the institutional history
A summary of what the standards-body story has cost, relative to what the web’s original design assumed:
The IETF’s volunteer-driven, broadly-participatory model has been displaced, for the web’s central standards, by a vendor-driven model. The shift may have been necessary (the IETF model probably could not have kept up with the browser pace) but it has narrowed the range of voices in the standards conversation.
The W3C’s broad membership has not, in practice, produced broad participation in the key decisions. Corporate members dominate; civil-society members participate at the margins; users are not represented except indirectly through the various advocacy organizations that try to speak for them.
The pace of standardization has lagged the pace of implementation. Features get shipped first and standardized after, which means the standards function more as documentation of decisions than as deliberative shaping of them. The window in which the broader web community could have influenced a feature’s design is, by the time the standard is being written, mostly closed.
The semantic web project, treated in passing in the academic-hypermedia chapter, was the most ambitious attempt to shape the web’s evolution through the standards process, and it has had limited results. RDF, OWL, SPARQL, and the Linked Data infrastructure exist and are used in specific domains, but the broader web has not adopted them. The reasons are many — the technologies are hard to use, the use cases were never as compelling as their proponents hoped, the browser vendors did not invest in supporting them — but the result is that the standards-driven attempt to give the web a richer semantic infrastructure has not produced the world it imagined.
What the institutional story has nevertheless preserved
The standards-body story has not been a story of pure decline. The institutions have continued to do real work and the work has had real effects.
HTTP has been substantially improved through the IETF process. HTTP/2 (RFC 7540 in 2015), which descended from Google’s SPDY protocol, brought multiplexing, header compression, and server push to HTTP, improving performance significantly. HTTP/3 (RFC 9114 in 2022), built on QUIC, has continued the improvements with better behavior over unreliable networks. The IETF’s standardization of these protocols has been competent, broadly participatory by the IETF’s standards, and successful in producing implementations that interoperate.
HTML5 has been a substantial success as a specification. The work began as a WHATWG revolt against the W3C’s XHTML 2.0 direction and ended as the foundational specification for the modern web. The specification is enormous and detailed; it documents the actual behavior of browsers across many edge cases that previous specifications had ignored; it has given web developers a clearer foundation to build on than they had before. The HTML5 work has been one of the most consequential pieces of standards work in the history of the web.
ECMAScript has, through TC39, evolved into a much more capable language than it was in 1996, while preserving compatibility. The 2015 edition (ES6) was a major upgrade; subsequent editions have added features steadily; the language is, in 2026, broadly considered fit for the wide range of uses it is put to. The standards process has worked.
CSS has been a quiet success of the W3C process. The various CSS modules — CSS3, CSS4 (as the next generation of features has come to be informally called), Grid, Flexbox, Container Queries, custom properties — have been produced through a careful, slow-moving working group process that has, in retrospect, served the web well. CSS’s reputation has improved over the decade since the modular approach matured; layout in modern browsers is much more capable than it was in 2010, and the standards process is largely responsible.
The accessibility standards, the internationalization standards, the various adjacent specifications that the W3C has continued to produce — these are real work, done by serious people, with real effects on the usability of the web for users who depend on them.
What this story leaves out
The chapter has focused on the institutions and the politics. It has left out, mostly, the people who do the work. The web’s standards are written by individual engineers and editors who spend their careers in the working groups, mailing lists, and conference calls of the standards bodies. Many of them are long-tenured experts whose names appear on dozens of specifications. They are, almost without exception, doing the work in good faith, trying to produce specifications that serve the web well. The institutional politics constrain what they can do; the politics do not make them villains.
The next chapter takes the language that became, for reasons no one in particular planned, the most-deployed runtime environment on the planet. JavaScript was an afterthought in the design of Netscape Navigator, was standardized in haste through ECMA, was reviled by most serious programmers through the 2000s, and is now the substrate of essentially every consumer application that runs in a browser. Its accidental dominance is one of the more peculiar stories in the history of computing, and its consequences for what the web has become are very large.