W3C vs. WHATWG HTML5 Specs – The Differences Documented
A few weeks ago, HTML5 became an official W3C Recommendation. I took advantage of this event to discuss 5 interesting but now obsolete featureson SitePoint. The problem is that the W3C specifications are only one side of the same coin. Starting from this version of HTML, developers and browser vendors can choose between two different flavors of the same markup language: the specifications developed by the W3C and those developed by the WHATWG.
For the most part, these specifications are the same or very similar but, as the years pass, more and more differences are arising. Should you care about them? In most cases you should not because either they will make little differences for you and your projects, or browser vendors will support both standards. However, in the short term other differences might be important for you as they affect the implementation of a given feature. Every browser vendor has its own take on what specification to follow. For example David Baron from Mozilla recently stated:
When the W3C’s and WHATWG’s HTML specifications differ, we tend to follow the WHATWG one.
In this article we’ll tackle some of the differences between the W3C and the WHATWG specifications and at the end of each of these sections I’ll give my opinion on the difference. This is not intended to be a comprehensive list but it should be enough to get your head around the issue.
“HTML5″ vs “HTML Living Standard”
Let’s start this discussion about the differences with a simple topic: the name of the standard. The WHATWG version of the specification wasrenamed at the beginning of 2011 to “HTML” dropping the “5” at the end of the name. Then, it was further renamed into “HTML living standard” to specify that it’ll be in constant development and will no longer referred by using a version number.
On the contrary, the W3C’s specifications still use version numbers and, as I mentioned in the introduction, the last stable version is 5, thus HTML5. As a consequence of this step, the consortium is now actively developing the new version of the standard known as HTML5.1. In HTML5.1 some elements and attributes that didn’t find their place in HTML5 are being discussed such as the dialog element and the new input types of month and week.
OPINION
I think that today’s world is really different from the early 2000s because technologies evolve at an even crazier pace, especially on the web. So, it sounds reasonable to have a sense of continuity, dropping any version number. However, not every browser auto-updates or is released at the same pace (the commonly used term is an evergreen browser), so it still makes sense to map a set of features to one or more browser versions.
My opinion is that until every browser adopts this policy of fast releases and auto-updates, having a version developers can refer to allows for better planning. Not because you should develop websites that detect the version of a browser to use a certain feature (you really should use the feature detection approach for this) but because with a specific version of a browser we can obtain statistics of its use. By using such statistics you can plan if it’s the right time to adopt a certain feature in your project. Yes, polyfills and shims can help but you need to consider how much weight are you willing to add to your website?
The main element
The main element is one the latest additions to the specifications and it has different meaning depending on the specifications. The W3C specifications describe it as the main content of the page – the content that describes the main topic of a page or is the central functionality of an application. The specifications also assert that a document must not include more than onemain element and that the main element has to be mapped to the ARIArole="main" or equivalent in accessibility APIs.
A simple example of use based on this specification is shown below:
<body> <header> <h1>Main title</h1> </header> <main> <article> <h1>Main title</h1> <p>This is the content of this section</p> <footer> The author of this content is Aurelio De Rosa </footer> </article> </main> <footer> <small>Copyright © Aurelio De Rosa 2014</small> </footer> </body>The WHATWG specifications don’t assign any semantic value to the mainelement and describe it as a container for the dominant contents of another element. If you adhere to the WHATWG specifications you don’t have a limit in the number of times you can use the main element. Therefore if you have multiple article elements on a page you might markup the content of each article with the main element.
An example of use based on the WHATWG specifications could be:
<body> <header> <h1>Main title</h1> </header> <main> <article> <h1>Main title</h1> <main> <p>This is the content of this section</p> </main> <footer> The author of this content is Aurelio De Rosa </footer> </article> </main> <footer> <small>Copyright © Aurelio De Rosa 2014</small> </footer> </body>Note how in the code above I used the main element twice.
OPINION
In regard to the main element, I’m with the W3C because I doubt that people have the need for multiple main areas in a document. In addition, I recall that Steve Faulkner (the editor of the W3C specifications) has urged Ian Hickson (the editor of the WHATWG specifications) multiple times on the WHATWG mailing list to show data that proved the need for multiple main areas. The conclusion was that in all the occasions the WHATWG editor failed in providing such data.
The hgroup element
The hgroup element is used to group a set of one or more h1-h6 elements, useful to group a section title and an accompanying subtitle.
This element was introduced to easily create subtitles and address an important problem in the document outline algorithm. In fact, when grouping multiple heading elements in an hgroup, the outline algorithm was supposed to mask all but the highest level heading in the group from the resulting document outline.
An example of its use, taken from my article 5 Obsolete Features in HTML5, is shown below:
<article> <hgroup> <h1>5 deprecated features of HTML5</h1> <h2>Sometimes specifications are changed and you need to refactor your code</h2> </hgroup> <p>In this article we'll discuss...</p> </article>In April 2013 this element was removed from the W3C’s specification due tolack of implementations, lack of use cases, and promoted markup anti-pattern
. On the contrary, the WHATWG spec still includes hgroup.
OPINION
As stated in the cited article, I’ve been a huge fan of this element but I dropped its use. The first reason for my choice is that I’m mostly a follower of the W3C specifications. The second reason is that I noticed this lack of interest and implementation among browsers.
Web Notifications API
The Web Notifications API is defined as an API for end-user notifications. A notification allows alerting the user outside the context of a web page of an occurrence, such as the delivery of email.
This API can be used to provide a notification as soon as your users receive an email or to notify them in case there’s an event they should pay attention to. Some concrete examples might be if someone mentions a user in a tweet, or posts a photo of you on Facebook or Google+.
A simple example of use of this API is shown below:
Notification.requestPermission(function() { var notification = new Notification('Email received', { body: 'You have a total of 3 unread emails' }); notification.onshow = function() { console.log('Notification shown'); }; });The Web Notifications API is specified by both the W3C specifications and the the WHATWG specifications with some differences between the two versions. In particular, the WHATWG specifications dropped the oncloseand the onshow events. So, while the W3C specifications define four events (onclick, onclose, onerror, and onshow), the WHATWG specifications only define two (onclick and onerror).
In case you want to learn more about the different versions of this API and what’s the support of the major browsers you can take a look at my articleThe state of the Web Notifications API.
OPINION
There aren’t many differences between the specifications but they affect the way you can perform certain tasks. In this case too I’m with the W3C specifications as I think there might be cases to perform actions when the close event is fired which is not possible by following the WHATWG specifications.
Conclusions
In this article we’ve discussed some of the most important differences between the W3C and WHATWG specifications. As you can see, considering the amount of elements and APIs defined in the specifications, there aren’t a lot of differences yet. With this in mind, I’m also not concerned about the future as I’m sure that in the end the specifications will simply match the reality. What this means is that regardless of what was specified by both the groups at the beginning of a feature, browsers and developers have the power to drive the success of one or the other version. So, browsers and developers are the actors that decide which specifications “win” by implementing or adopting them. Because of this, for each feature discussed, the group that will “lose” the battle will end up adapting the specifications to match the reality.
As a final note, in case you want to discover some more differences, you can take a look at the page Differences between the W3C HTML 5.1 specification and the WHATWG LS by the W3C.