As the Internet has grown into what it is today, the HTML specification has grown with it. As far back as 2008, there was discussion about breaking it up into separate specs. An email by Ian Hickson draws attention to where the W3C was at that time. In it, he suggests a few sections to take out of the Core spec, including the 2D Canvas, 3D Canvas, Stylesheet API, Interaction events, as well as HTML5 Rendering and UA behavior.
Despite the effort spent on splitting up the HTML spec, the W3C didn’t make any major changes until HTML5. Some of these changes were outlined in the The HTML5 Spec: What’s In and What’s Out? article. Today’s follow-up will attempt to demystify the dozens of periphery working groups that produce specs that are not part of the core HTML5 Spec.
How to Tell if an API is Part of the Core Spec
Here’s a riddle: How do you know whether a spec is part of the HTML5 Core or not?
Or in this case, read the spec. Though it might sound like an egregious oversimplification: if it’s in the spec, it’s part of the standard; if it isn’t, it’s a separate spec.
With that rule of thumb in mind, the W3C’s most recent recommendation for HTML5 is posted on their site for all to see. That spec defines the 5th major revision of the core Hypertext Markup Language (HTML). It includes new features that were introduced to help Web application authors, new document elements, as well as conformance guidelines for browser vendors that may lead to improved interoperability.
If you like a good picture as much as I do, then you’re going to love this graphic that I came across on the Repository of all worldly knowledge, Wikipedia:
The above image clearly delineates the initial W3C HTML5 and WHATWG HTML specifications, the official W3C HTML5 specification, and HTML5 & related technologies.
It is very telling because we can see that the Core HTML5 spec came to include much more that HTML Markup, including APIs for Canvas, Drag-and-drop, Web Messaging, and others. That being said, a search for “drag and drop” in the W3c spec will hit in working drafts, but will come up empty in the latest version. While the W3C decided to not include the Drag & Drop API in their spec, the WHATWG did. That’s why the label for the innermost circle of the diagram is “WHATWG HTML Specification”. The Web Hypertext Application Technology Working Group (WHATWG) is a competing organization that also produces specifications for the Web. Just like the W3C, the WHATWG focuses on the development of HTML and APIs for Web applications.
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera did not agree with the W3C’s direction in a few areas, including HTML, XHTML, and felt that the group has started to disregard the needs of HTML authors. So, in the spirit of the open market, these organizations created their own community.
Both groups’ specifications tend to be very similar but, over time, more and more differences are cropping up. One of the most striking differences is the naming of the standard. The WHATWG version of the specification was renamed into “HTML living standard” with reference to the constantly evolving nature of the spec. Meanwhile, the W3C’s specifications still use version numbers and is now working the next version of their standard known as HTML5.1.
Browser vendors must choose whether to support both standards or follow one over the other. For instance, when the W3C’s and WHATWG’s HTML specifications differ, Mozilla tends to follow the WHATWG one.
The remaining peripheral specifications are drafted by members of the W3C within various working groups. Here are a few examples:
- Geolocation: the Geolocation Working Group is tasked by the W3C to define a secure and privacy-sensitive interface for using client-side location information in location-aware Web applications. The group meets regularly by phone and has two to three Face-to-Face meetings per year.
- File API: Currently in the last call stage of development, the latest spec was published by the Web Applications Working Group on April 21, 2015. This group is chartered to develop specifications for web apps, including standard APIs for client-side development, and a packaging format for installable web apps. Their work includes both documenting existing APIs such as XMLHttpRequest and developing new APIs in order to enable richer web applications.
- Cascading Style Sheets: The CSS Working Group is responsible for both for the CSS specifications and for their conformance test suites. Their roadmap is maintained on the W3C website.
A full listing of the W3C Groups can be found on this W3C page.
With the current volume of APIs supported by modern browsers, it only makes sense to divvy them up into separate working groups. The only drawback is that it can be difficult for web developers to track down the relevant spec for a given technology. As summarized in this article, perhaps the best approach would be to first refer to the Core HTML5 spec. Then, if the API you are looking for is not contained therein, consult the W3C’s list of working groups. Finally, perform a web search for external working groups. That will almost certainly lead you to what you seek.