Finishing HTML5.1 … and starting HTML 5.2
Author(s) and publish date
- By:
-
-
Charles McCathie Nevile
-
- Published:
Since we published the Working on HTML5.1 post, we've made progress. We've closed more issues than we have open, we now have a working rhythm for the specification that is getting up to the speed we want, and we have a spec we think is a big improvement on HTML5.
Now it's time to publish something serious.
We've just posted a Call For Consensus (CFC) to publish the current HTML5.1 Working Draft as a Candidate Recommendation (CR). This means we're going into feature freeze on HTML5.1, allowing the W3C Patent Policy to come into play and ensure HTML5.1 can be freely implemented and used.
While HTML5.1 is in CR we may make some editorial tweaks to the spec - for instance we will be checking for names that have been left out of the Acknowledgements section. There will also be some features marked "at risk", which means they will be removed from HTML5.1 if we find during CR that they do not work in at least two shipping browsers.
Beyond this, the path of getting from CR to W3C Recommendation is an administrative one. We hope the Web Platform WG agrees that HTML5.1 is better than HTML5, and that it would benefit the web community if we updated the "gold standard" - the W3C Recommendation. Then we need W3C's membership, and finally W3C Director Tim Berners-Lee to agree too.
The goal is for HTML5.1 to be a W3C Recommendation in September, and to achieve that we have to put the specification into feature freeze now. But what happens between now and September? Are we really going to sit around for a few months crossing legal t's and dotting administrative i's? No way!
We have pending changes that reflect features we believe will be shipped over the next few months. And of course there are always bugs to fix, and editorial improvements to make HTML at W3C more reliable and usable by the web community.
In the next couple of weeks we will propose a First Public Working Draft of HTML5.2. This will probably include some new features, some features that were not interoperable and so not included in HTML5.1, and some more bug fixes. This will kick off a programme of regular Working Draft releases until HTML5.2 is ready to be moved to W3C Recommendation sometime in the next year or so.
As always please join in, whether by following @HTMLWG on Twitter, filing issues, joining WP WG and writing bits of the specification, or just helping your colleagues stay up to date on HTML...
… on behalf of the chairs and editors, thanks!
HTML 5.2 already ? I have to update my website before ! ^^
No doubt these updates and development have made a huge difference in bringing down the complexities. #HTML has become so powerful that static sites are becoming more of a choice.
Actually, I think the things people try to do have grown at least as fast as the capacity of HTML to do them declaratively. So yes, there are more things that can be done declaratively, making development easier and more reliable.
But there are also ever-more complex things people try to do with interaction in applications. There are also areas where we haven't yet worked out the right way to do things declaratively. One good example is complex form widgets like date pickers. As Brian Kardell wrote recently when discussing this topic,
videois an example where we have made a lot of progress.There is a lot of discussion all over the internet (and outside it, in real live chats between actual people), about fixing more bits of the puzzle. It's what we do in the Web Platform group, and at an earlier stage in WICG developing HTML but also lots of DOM APIs, that will one day turn into new declarative ways of doing things. And more generally, what W3C - which really means the people who participate in the work - does for the Web…
Wow this is called the real pace. I am still learning HTML 5.1 and 5.2 is about to be released.
With regular releases, we hope to update little and often - to make it easy for developers to move from one stable version to the next.
Am still learning Html 5.1 now we are talking of Html 5.2, this is coming like a flash.
If there are things you think we can improve in 5.2, you can let us know on the Github HTML repo. We'd really like to hear from developers on the things that are important in HTML.
I would like to be able to interact with mobile hardware (GPS, sensors, leds, camera) through HTML. That would really lead to code all mobile apps on HTML.
The geolocation API lets you interact with whatever sources of location information the device has, assuming the user gives permission, in HTML. This has been around for some years, and W3C is looking at modernising it.
Similarly, the API around
getUserMedia()lets you access cameras, microphones, and the like in HTML, and the Vibration API, provides what you would expect.In development there are the DeviceOrientation, Battery status, Wake Lock, Ambient Light and generic sensor APIs. Some of these are already pretty widely implemented.
The "HTML world" - what we sometimes call "the Open Web Platform" - is much bigger than just HTML itself, or even the "big 3" of HTML, CSS and Javascript.
It seems like you'd get some good value from a quick look into the range of specs W3C produces, and how widely they each work...
When will I be able to use HTML5.1 features such as sortable tables?
I'm afraid sortable tables is one of the features that was proposed for HTML 5.0, but didn't get implemented. So it isn't in HTML 5.1, because we have worked hard to make that spec more realistic.
On the other hand there are features like the
pictureelement, orsrcsetattribute, that are part of HTML 5.1 and that you can use now. Likewise thesummaryanddetailselements work in some browsers already...What's new with HTML 5.1?
Also, will we get sass/scss features soon for CSS with nesting and more stuffs to remove JS completely in the futur for onclick, onhover and more events?
Very nice and informative.
There is no doubt that HTML5 is one of the most decent, usable language and will be upgraded to 5.2 in order to provide less effort and more getting in return.