On the 21st of June 2016, HTML 5.1 has turned from being a Working Draft into a Candidate Recommendation. As you might know, this is the second step of the process that turns proposals into the standards that affect our lives daily when developing for the web. Because it has become a Candidate Recommendation, HTML 5.1 is
a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements.
A few days ago, HTML 5.1 was proposed to be moved to the third step: Proposed Recommendation (PR). This means that only very minor tweaks will be performed on the specifications before it reaches the final stage of W3C Recommendation.
Having moved HTML 5.1 close to the final stage, the working group has now started focusing its attention on the future. As a result, the group has officially started working on HTML 5.2 which is now a Working Draft. Therefore, the HTML 5.2 specifications are a
document that W3C has published for review by the community, including W3C Members, the public, and other organizations.
HTML5 has taken the web by storm in terms of semantic, accessibility, and APIs available without the need for third-party dependencies. We can consider it a revolutionary technology. HTML 5.1 has taken all the good features of its predecessor and introduced some important improvements such as new semantic elements. Considering what HTML 5.1 has brought to the table, it's reasonable to think that HTML 5.2 will do the same and enhance HTML even more.
In this article, I'll offer a short overview of the evolution that HTML, including features introduced or removed in HTML5, HTML 5.1, and HTML 5.2. Hopefully this article will help you fill in any of the knowledge gaps you might have.
In particular, I will focus on:
One of the greatest innovations HTML 5.1 brought was the introduction of new semantic elements. They have probably (and hopefully) become part of your daily writing routine by now. Thanks to them, the structure and semantics of our markup and, as a consequence, of our websites has improved a lot.
Among the most important elements we can mention are:
<main>for the main content;
<nav>to define a major block or set of navigation links;
<article>for independent content, that can be placed independently from the rest of the site;
<header>for introductory content or a set of navigation links;
<footer>that defines a footer for a document or section (and generally contains authorship, copyright, contact information or a sitemap);
<aside>for the content aside from the content it is placed in and
<section>to define a specific section in a document.
A separate mention goes to two other revolutionary elements which have helped us in removing the need for technologies like Flash:
<audio>used to embed sound content in documents;
<video>employed to embed video content in a document;
Among all of the above, the most controversial one is surely the
<main> element. The W3C specifications describe it as the main content of the page, while the WHATWG defines it as a container for the dominant contents of another element. Because of this difference, the WHATWG specifications don't limit the number of times you can use the
main element in a document. According to the WHATWG, if you have multiple
article elements on a page you might markup the content of each article with the
The two specifications have other differences such as the presence of the
<hgroup> element. I'm not going to cover them in this article. If you are curious about this topic and want to learn more about it, there is an article authored by Aurelio De Rosa titled W3C vs. WHATWG HTML5 Specs – The Differences Documented that you'll find very informative.
Let's now have a look at the differences between HTML5 and HTML 5.1.
In this section I'll discuss the elements, methods, and attributes that have been introduced and are now at risk in HTML 5.1. For each of them, I'll mention what they are, their benefits, and provide additional resources and references so that you can learn more if interested. It's worth noting that most of these new elements were proposed in HTML5 but didn't make it for several reasons, so they might not sound new to you. An example of elements that were moved from the HTML5 to the HTML 5.1 specifications are
Just like any other specifications, HTML 5.1 also introduced features that were removed shortly thereafter. An example is the
inert attribute, whose introduction was proposed in 2014. As you can read in this short discussion on GitHub, this attribute has been dropped since its use case was subsumed by the
Let's start with the new elements.
The first element I want to discuss is the
<picture> element. It's used in combination with the
source element and the
srcset attribute, and it can be used to serve a smaller image, in size and weight, when the web page is loaded on a small screen (e.g. a mobile device).
Another use case of
<picture> is to serve an image at a higher density when the page is loaded on a high resolution screen. Thanks to this element, you can show better images to your users and improve the performance of your website by avoiding large, high-density images when inappropriate. If you want to know more, I wrote two articles on the topic: Improving Responsive Images with the Picture Element and Responsive Images, Part 1: Using srcset. Some have argued that you don't need
picture (most of the time), but I'll leave the decision up to you.
Next let's look at
<dialog> element, which is currently supported by Chrome and Opera, and under consideration in Microsoft Edge. It can be used to represent a dialog box, an inspector, or a window.
<form> elements can be integrated in a
<dialog> by employing the
method attribute with a value of
dialog. When such a form is submitted, the dialog is closed with a
returnValue attribute set to the value of the submit button used. A live demo of this element, taken from the MDN, is available as a JSFiddle.
<details> and the
<summary> elements are another nice addition. The
<details> element represents a disclosure widget from which the user can obtain additional information or controls. It works in conjunction with the
<summary> element that is used as a summary, caption, or legend for the content of a
<details> is currently supported by Chrome, Firefox (version 49+), Opera, and Safari. In my opinion these elements will be used a lot in the near future to create collapsible/expandable components.
In addition to these elements, HTML 5.1 has also brought the following additions:
weekvalues of the
typeattribute of the
<input>element. As their name suggest, they define controls for setting the element's value to a string representing a month and a week.
forceSpellcheck()method has been added to the
HTMLElementinterface and allows you, as a developer, to force the user agent to perform a spelling and grammar check on the element it is invoked on, even if the user has not focused it. An example of usage would be
inputElement.forceSpellcheck(). Unfortunately, no browsers support it yet.
allowfullscreenattribute is a Boolean attribute for the
iframeelement and it specifies that the
iframeis allowed to be in full screen mode when calling the
requestFullScreen()method. If this isn't set, the element can't be in full screen mode.
reportValidity()method, when invoked, forces user agent to validate the constraints of the
<form>element. Some examples are to check if a
requiredelement has not been filled or if a field respects its
patternattribute. It returns
trueif the constraint validation returns a positive result or
falseotherwise. This method is currently supported by Chrome and Opera.
The HTML 5.1 specifications also describe features that are considered "at risk".
The first feature at risk I want to mention is the
<menu> element. It represents a set of menu commands and it was originally designed to create toolbars and popup menus. Nowadays Chrome and Opera implement it behind the Experimental Web Platform features flag and it only works as a context menu, not as button menu. The same goes for the most recent version of Firefox, while there is no support on the other remaining browsers.
Another feature is the
<menuitem> element. It represents a command that a user is able to invoke through a popup menu. This includes context menus, as well as menus that might be attached to a menu button. In Chrome and Opera it is implemented behind the Experimental Web Platform features flag and only supports
type="command". In Firefox, it requires a closing tag and only works when defined within a
<menu> element assigned to an element via the
contextmenu attribute. It is not supported in Internet Explorer nor in Edge.
Another element that has been included in the features at risk is
<keygen>. It represents a key pair generator control. When the control's form is submitted, the private key is stored in the local keystore, and the public key is packaged and sent to the server.
In addition to these elements, the following features are also considered at risk:
datetime-localvalues for the
typeattribute of the
<input>element. The former attribute can be used to define a specific global date and time, while the latter represents a local date and time, with no time-zone offset information.
contextattribute specifies a context menu for a
<div>element and appears when a user right-clicks on the element. Among the browsers, Firefox is the only one that supports this attribute.
inputmodeattribute. It specifies what kind of input mechanism is more helpful for users when entering content into the form control.
Now that you know what HTML 5.1 has changed, it's time to take a step further and see what the working group behind the HTML specifications is working on.
The work for creating the specifications of HTML 5.2 has just started, so as you can imagine not much has been done at the moment.
One of the most important features that will be discussed as part of the creation of HTML 5.2 is the addition of
Another feature under development is the addition of the
<meta name="theme-color"> definition. Its value can be any color definition that you can use in CSS, including HEX and RGB values. When included in a web page, this new meta tag suggests a color that browsers and operating systems should use if they customize their UIs. You can already see this behavior in action when using Chrome on Android as shown in the image below:
The standardization of an
autocapitalize attribute is also under discussion. It's currently supported by Safari on iOS with two different implementations depending on the version. Older versions (prior to iOS 5) implement it as a boolean attribute, while newer versions accept different values. A proposal has been created to have this attribute supported by all browsers in a unique way.
As a final note, I'd like to mention this discussion about what to do with a concept known as the outline algorithm. The outline algorithm is a mechanism for producing outline summaries of web pages based on the structure of sectioning elements (such as
section) rather than the heading levels. In theory, you could use all
h1s on a page as long as you surround them with the proper sectioning elements that create a structured document. In practice, it has never been implemented by any user agent and relying on it in your website is dangerous.
In addition to developing new features, a focus is also being put on aligning browser implementations of existing features. One example is the behavior of the
<input> element when it is associated with a
If you want to have a more detailed idea of the other topics the working group will focus its attention to, take a look at this GitHub issue.
I hope that I was able to give you a solid overview of the most important changes that HTML has seen in the last decades. I think that it illustrates how difficult it is for developers to follow all of the evolutions of the web.
Header image courtesy of Markus Tacker