See also the HTML Standard FAQ.
The Web Hypertext Application Technology Working Group (WHATWG) is a community of people interested in evolving the web through standards and tests.
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML, and apparent disregard for the needs of real-world web developers. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.
In 2017, Apple, Google, Microsoft, and Mozilla helped develop an IPR policy and governance structure for the WHATWG, together forming a Steering Group to oversee relevant policies.
It is spelled WHATWG, all uppercase, no spaces. It has various pronunciations: what-wee-gee, what-wig, what-double-you-gee.
The WHATWG’s focus is on standards implementable in web browsers, and their associated tests. Our existing work can be seen on the standards page.
There are lots of ways you can get involved! You might want to get started by reviewing the standards and filing issues. You can also browse our list of good first issues on GitHub, if you're interested in helping us editing the standards directly. Also, feel free to join Chat and ask questions of other community members.
For more information, see our dedicated site at participate.whatwg.org. Additionally, this video from Domenic Denicola is a good introduction to working with standards bodies.
Yes, everyone can contribute. There are no memberships fees involved; it’s an open process. See our participation page for more information. Participation can be done entirely over the internet; no binding decisions are made during in-person meetings. That is, decisions made during the odd meeting are tentative and subject to appeal from those not present.
Working Mode describes the day-to-day process in detail. Most of the activity consists of collaboration on GitHub.
In brief, each standard has one or more editors, who guide its evolution. Like a software project, a WHATWG standard undergoes continual maintenance, and occasionally gets new features. This work is driven by the community in collaboration with implementers.
Much of the time, discussions in the WHATWG are straightforward, with everyone collaborating on an effort to change the standard according to our working mode. As a community, we evaluate suggested changes on their merit, and convince one another as to the right path forward.
In cases where community members disagree, the burden is on the editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).
The purpose of debate at the WHATWG therefore isn’t to convince everyone; it is to put forward the arguments that exist, so that the relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn’t help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people’s argumentation behaviour, we stop making any kind of useful progress, since that isn’t input that can help the decision-making process later.
The WHATWG strives for rough, informal consensus among contributors when drafting Living Standards. After considering input from all parties, the editor of a Living Standard makes the judgment as to whether a feature has enough support behind it to include. Those disagreeing with the editor's judgment can, under what we hope are exceptional circumstances, appeal to the Steering Group, which does have a formal consensus policy.
For more information on how decisions are made, see the Working Mode.
The community working there. Living Standards are informed by input from contributors, driven by workstream participants, articulated by editors, and coordinated by the Steering Group. If necessary, controversies are resolved by the Steering Group with members appointed from the organizations that develop browser engines, as a backstop to ensure the editor's judgment aligns with what they will implement. Substantive technical objections are considered and resolved by the Steering Group, consistent with the principles of the WHATWG.
File an issue on the relevant standard as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.
If you want feedback to be dealt with faster than “eventually”, e.g., because you are about to work on that feature and need the standard to be updated to take into account all previous feedback, let the editors know by either emailing them, or contacting them on IRC. Requests for priority feedback handling are handled confidentially if desired so other implementers won’t know that you are working on that feature.
In general, it is very hard to remove features from the web platform, as implementers are hesitant to break web pages. Remember that WHATWG standards are intended to align with the reality of what implementers support and web pages use; they are not meant to be perfect reflections of a pure platform with no rough edges.
That said, we do sometimes remove things from the platform! This is usually a very tricky effort, involving the coordination among multiple implementations and extensive telemetry to quantify how many web pages would have their behavior changed. But when the feature is sufficiently insecure, harmful to users, or is used very rarely, this can be done. And once implementers have agreed to remove the feature from their browsers, we can work together to remove it from the standard.
A recent removal from the platform is the
AppCache feature. Other notable removals
are the applet and
keygen elements. An in-progress
removal, which may or may not be successful, is
synchronous XMLHttpRequest.
The process is rather informal, but basically boils down to this:
Forget about the particular solution you have in mind! Solution time is later!
Write down a description of the underlying problem you’re trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see this email.
Get more people involved. Open a new issue in whatwg/html on GitHub that describes the use cases and their requirements. Ask fellow web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.
Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)
Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there’s implementation experience). Send this list of solutions, old and new, as a comment on the feature’s issue. Ask browser vendors for feedback. Maybe some particular solutions don’t fit with the browser’s architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don’t grieve about the loss!
Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else’s solution).
Get multi-implementer interest in the solution. This means a commitment from two or more browser engines to implement and ship your feature. Many features get stuck here; don't get too discouraged! Browsers are tough, resource-constrained software projects. If they aren't able to immediately prioritize your feature, you can try to raise the profile of your problem via community outreach. A commonly-successful way of doing this is to create a polyfill for your solution, and show that it gets very wide use, and is thus worth shipping with the browser.
Once you have multiple implementers on board, ask the editor to put that solution in the standard, or create a pull request on GitHub yourself. Possibly your text won’t be taken verbatim, but will be written in a style that is more suitable for implementers or better hooks in to the rest of the standard, etc.
Write a test suite for the feature to help along the implementations. Cross-browser tests are maintained in web-platform-tests on GitHub. Implementers are often much more eager to add a feature when someone else has provided them with a comprehensive test suite. As a bonus, this often also finds bugs or imprecisions in the proposed standard. Note that writing comprehensive tests for a complex feature before it has been implemented at all is difficult and error-prone, and in such cases you might want to work with the implementers to develop the test suite in tandem with their initial implementations.
At this point, if the editor judges everything is all lined up, the pull request for your feature will be merged into the standard! But you're not done yet.
Ensure that browser vendors follow up and ship the newly specified solution. This process sometimes finds new problems with the solution that need to be addressed, or even discovers that a different solution is actually better.
Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases, repeating this process.
This whole process can be very short (a couple months), or very long (years).
For more information on the formalized requirements for adding new features, see our working mode.
This is a great idea for grammatical or typographical errors! However, usually, you want to open an issue first. Although sending a pull request is eventually part of the process, doing so before discussion with the community and editor(s) can result in wasted work on your part. For suggestions that are actually new features, this is especially important; see the answer above for how things usually work.
The WHATWG standards are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from web developers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the standard a little ahead of the implementations, but not so far ahead that the implementations give up.
Despite the continuous maintenance, or maybe we should say as part of the continuing maintenance, a significant effort is placed on getting the standard and the implementations to converge — the parts of the standard that are mature and stable are not changed willy nilly. Maintenance means that the days where the standard are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the standard left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the standard to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the standard to match what the browsers do. Instead of leaving the standard ambiguous, we fix the the standard to define how things work.
The standards do not change arbitrarily: we are extremely careful! As parts of a standard mature, and implementations ship, the standard can generally not be changed in backwards-incompatible ways without extreme care, and with implementer commitments leading the way.
The standards are never complete, since the web is continuously evolving. The last time HTML was described as “complete” was after HTML4, when development stopped for several years, leading to stagnation. (If the web is replaced by something better and dies, the HTML Standard will die with it.)
For references to specific copies of the standard, for example to document when an implementation was last updated to keep pace with the standard, all WHATWG standards follows a process by which each change to the standard (embodied in a commit) triggers the publication of a frozen snapshot of the said standard. These snapshots are published as historical references. The WHATWG intends to keep these frozen snapshots available at their published URL permanently.
We think of stability for standards in the same way as we do for software. When one says that software is stable, one doesn't mean that it never changes: one instead means that it evolves carefully, not breaking backward compatibility, with bugs continually being found and fixed. Software that is never patched has a low chance of being stable, as bugs sit unaddressed.
So in this sense, unlike "dead standards" that are published once and never change, WHATWG Living Standards are quite stable: they endeavor to eliminate all of their bugs, instead of leaving them unaddressed.
In non-normative layperson's terms: roughly every six months, a Living Standard is “snapshotted” to create a Review Draft suitable for patent review. All workstream participants, by virtue of signing the IPR Policy, commit to licensing any essential claims they may have, unless they exclude those claims within 45 days of the publication of that snapshot.
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original standard, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g., the Streams Standard.
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it’s possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.
Note that WHATWG standards are always licensed under liberal licenses that allow the creation of derivative works like translations.