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 &copy; 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 &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 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 (onclickoncloseonerror, 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.

W3C vs. WHATWG HTML5 Specs – The Differences Documented的更多相关文章

  1. html5 基本内容 摘自W3C

    HTML5 教程(摘录自 W3C School) HTML 5 简介(HTML5 是下一代的 HTML) 什么是 HTML5? HTML5 将成为 HTML.XHTML 以及 HTML DOM 的新标 ...

  2. IT兄弟连 HTML5教程 HTML5的靠山 RFC、WHATWG是什么WEB的新标准

    RFC是什么 RFC文档也称请求注解文档(Requests for Comments,RFC),这是用于发布Internet标准和Internet其他正式出版物的一种网络文件或工作报告,内容和Inte ...

  3. HTML5移动Web开发(三)——在移动网站中使用HTML5

    创建一个简单得HTML5页面ch01e2.html <html> <head> <meta name="viewport" content=" ...

  4. HTML5本地存储(Local Storage) 的前世今生

    长久以来本地存储能力一直是桌面应用区别于Web应用的一个主要优势.对于桌面应用(或者原生应用),操作系统一般都提供了一个抽象层用来帮助应用程序保存其本地数据 例如(用户配置信息或者运行时状态等). 常 ...

  5. html5的离线存储问题集合

    HTML5的离线存储使用一个manifest文件来标明哪些文件是需要被存储的,使用如 来引入一个manifest文件,这个文件的路径可以是相对的,也可以是绝对的,如果你的web应用很多,而且希望能集中 ...

  6. HTML5简介

    HTML5简介 HTML5是HTML的最新修订标准.2014年10月29日,万维网联盟(W3C)宣布,经过8年的努力,HTML5标准规范制定完成. HTML5的设计目的是在移动设备上使用多媒体. HT ...

  7. HTML最新标准HTML5小结

    写在前面 HTML5出来已经很久了,然而由于本人不是专业搞前端的,只知道有这个东西,具体概念有点模糊(其实就是一系列标准规范啦):因此去年(2015.11.09),专门对HTML5做了个简单的小结,今 ...

  8. HTML5定稿

    HTML5定稿了,终于有一种编程语言开发的程序可以在Android和IOS两种设备上运行了 本文转载自: http://www.cnblogs.com/tuyile006/p/4103634.html ...

  9. HTML5扩展之微数据与丰富网页摘要

    一.微数据是? 一个页面的内容,例如人物.事件或评论不仅要给用户看,还要让机器可识别.而目前机器智能程度有限,要让其知会特定内容含义,我们需要使用规定的标签.属性名以及特定用法等.举个简单例子,我们使 ...

随机推荐

  1. IAP内购 返回的产品数量为0

    上个月搞IAP,提交到appstore审核被拒,根据附件截图 可以知道是请求产品信息的时候,产品数量返回0了. 返回产品数量为0 要么是Itunes Connect 里面的Contracts Tax ...

  2. Java语言基础(三)

    Java语言基础(三) 一.    补码 (1).之所以有补码是因为要考虑成本 就是造计算机的成本 (2).下面让我们分析一下补码 以四位补码为例 <1> 高位是符号位,它决定其是正数还是 ...

  3. 使用org.apache.jasper.JspC编译jsp文件--转载

    JspC可以通过jspc.setArgs(args);设置所需参数,和使用指令进行编译相同, 使用指令编译范例: java -cp jasper.jar;servlet-api.jar;Fcatali ...

  4. iOS UIKit:viewController之层次结构(1)

    ViewController是iOS应用程序中重要的部分,是应用程序数据和视图之间的重要桥梁.且应用程序至少有一个view controller.每个view controller对象都负责和管理一个 ...

  5. SQL Server 2008 安装指南

    一.安装需求: 1.硬件需求条件 硬件 需求 处理器 最低:1.4 GHz(x64处理器)注意:Windows Server 2008 for Itanium-Based Systems 版本需要In ...

  6. 点击其它地方隐藏div/事件冒泡/sweet-alert阻止冒泡

    点击document时把div隐藏,但点击div时阻止点击事件冒泡到document,从而实现“点击文档其它地方隐藏div,点击div本身不隐藏”.js代码如下:$("#div") ...

  7. [o] duplicate column name: _id 问题解决

    Android下使用SQLite数据库,报错:duplicate column name: _id 数据库文件下有两列数据的名称一样,原因是定义数据类型时有重复,如,我的定义: //复制上一行增加TY ...

  8. OpenGL ES 3.0 点,线,三角形绘制形式总结

    OpenGL ES 3.0 顶点     -1,  1, 0, -0.5f,  0, 0,     0, -1, 0,    -1,  0, 0, 0.5f,   0, 0,     1, -1,   ...

  9. Dictionary的遍历和修改

    /// <summary>        /// 初始化一个Dic        /// </summary>        public static void mainTe ...

  10. 微软企业库Microsoft Enterprise Library的相关文章链接

    微软企业库4.1学习笔记 http://blog.csdn.net/anyqu/article/category/1228691/3 黄聪:Enterprise Library 5.0 系列教程 ww ...