W3C vs. WHATWG HTML5 Specs – The Differences Documented

w3c_whatwg_header

A few weeks ago, HTML5 became an official W3C Recommendation. I took advantage of this event to discuss 5 interesting but now obsolete features on 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 was renamed 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 of 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 one main element and that the main element has to be mapped to the ARIA role="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 &copy; Aurelio De Rosa 2014</small>
   </footer>
</body>

The WHATWG specifications don’t assign any semantic value to the main element 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 &copy; 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 h1h6 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 to lack 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 onclose and 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 article The 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.

Comments

  • wengeezhang

    great job! I agree with you on main element.However i still use hgroup element!

  • brianm101

    Just shows what a bunch of morons are running so called web standards, no one benefits by having competing standards, calling it a standard is a misnomer in the first place anyway. As W3C is probably the closest we have to a standard please everyone tell the idiots running WHATWG to stop being idiots and go with a unified standard. Don’t care what the details of the standard are, just want one fixed standard!

    • Well, while I’m a big W3C fan, you should now that HTML5 would probably not be there without the WHATWG initiative. No additional features were added to HTML which itself was deprecated in favor of a more limited XHTML. Standardisation is a hard process that can take years. Some web specifications moved at W3C from Web Application, to Device API, to System Application Working groups, then moving back to previous working group while the latest is abandoned…

      Whatever happens at the standardisation level, Browser vendors still continuously try to integrates new features, so having an alternate living standard can help, and it is actually very often a motor in which innovations occurs first before coming to W3C (ex: http://www.w3.org/TR/streams-api/ based on https://streams.spec.whatwg.org/ ). As another example, JS Promises started on CommonJS wiki, to become WHATWG Futures, then WHATWG Promises, with integration in W3C APIs, before ending in ECMAScript 6.

      So my point is “idiots” really badly represent people running and/or working at WHATWG. everyone does its best to make the Web the best platform it could be. So yes, often some people disagree with each other but at least nothing get stuck, and progress is still going on for our own goods.

      By the way, thanx to Aurelio for its nice articles. I missed this Web Notification difference, so thanks for mentioning it 😉

      • brianm101

        Unfortunately which ever way you cut it having more than a single standard is just crazy! Nothing wrong with a group setting up to advise and try out ideas that might become part of a ‘uni’ standard one day,but as soon as the word alternative comes into play, then there is a problem and standardisation is lost. Standard are often about comprimise rather than perfection!

        W3C has done a lot to reduce the image of the internet/web technologies as cowboy territory, rival standards just throw us back to the ‘good old days’!

        • brianm101

          PS the photo at the top of the article about sums it up (nice illustration as well!)

  • Altiano Gerung

    it’s 2016.. who win? what standard chrome , microsoft edge and opera use?

  • Jason Amaro Reinert

    great article. Appreciate your work.
    Although I appreciate what WHATWG did
    in helping HTML5’s spec development and pushing into mainstream, I think the need has now died off. W3C display a better objectivity and sensibility in their decisions as well as being the established Specification source for the web. Having multiple is problematic and, as stated, it really only serves a short term purpose IMO which is now over.