HTML5 was released in 2014 as the result of a concerted effort by the W3C HTML Working Group. The intention was then to begin publishing regular incremental updates to the HTML standard, but a few things meant that didn’t happen as planned. Now the Web Platform Working Group (WP WG) is working towards an HTML5.1 release within the next six months, and a general workflow that means we can release a stable version of HTML as a W3C Recommendation about once per year.
The core goals for future HTML specifications are to match reality better, to make the specification as clear as possible to readers, and of course to make it possible for all stakeholders to propose improvements, and understand what makes changes to HTML successful.
The plan is to ship an HTML5.1 Recommendation in September 2016. This means we will need to have a Candidate Recommendation by the middle of June, following a Call For Consensus based on the most recent Working Draft.
To make it easier for people to review changes, an updated Working Draft will be published approximately once a month. For convenience, changes are noted within the specification itself.
Longer term we would like to “rinse and repeat”, making regular incremental updates to HTML a reality that is relatively straightforward to implement. In the meantime you can track progress using Github pulse, or by following @HTML_commits or @HTMLWG on Twitter.
Working on the spec…
The specification is on Github, so anyone who can make a Pull Request can propose changes. For simple changes such as grammar fixes, this is a very easy process to learn – and simple changes will generally be accepted by the editors with no fuss.
If you find something in the specification that generally doesn’t work in shipping browsers, please file an issue, or better still file a Pull Request to fix it. We will generally remove things that don’t have adequate support in at least two shipping browser engines, even if they are useful to have and we hope they will achieve sufficient support in the future: in some cases, you can or we may propose the dropped feature as a future extension – see below regarding “incubation”.
HTML is a very large specification. It is developed from a set of source files, which are processed with the Bikeshed
preprocessor. This automates things like links between the various sections, such as to element definitions. Significant
changes, even editorial ones, are likely to require a basic knowledge of how Bikeshed works, and we will continue to improve the
documentation especially for beginners.
HTML is covered by the W3C Patent Policy, so many potential patent holders have already ensured that it can be implemented without paying them any license fee. To keep this royalty-free licensing, any “substantive change” – one that actually changes conformance – must be accompanied by the patent commitment that has already been made by all participants in the Web Platform Working Group. If you make a Pull Request, this will automatically be checked, and the editors, chairs, or W3C staff will contact you to arrange the details. Generally this is a fairly simple process.
For substantial new features we prefer a separate module to be developed, “incubated”, to ensure that there is real support from the various kinds of implementers including browsers, authoring tools, producers of real content, and users, and when it is ready for standardisation to be proposed as an extension specification for HTML. The Web Platform Incubator Community Group (WICG) was set up for this purpose, but of course when you develop a proposal, any venue is reasonable. Again, we ask that you track technical contributions to the proposal (WICG will help do this for you), so we know when it arrives that people who had a hand in it have also committed to W3C’s royalty-free patent licensing and developers can happily implement it without a lot of worry about whether they will later be hit with a patent lawsuit.
W3C’s process for developing Recommendations requires a Working Group to convince the W3C Director, Tim Berners-Lee, that the specification
“is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized”
This had to be done for HTML 5.0. When a change is proposed to HTML we expect it to have enough tests to demonstrate that it does improve interoperability. Ideally these fit into an automatable testing system like the “Webapps test harness“. But in practice we plan to accept tests that demonstrate the necessary interoperability, whether they are readily automated or not.
The benefit of this approach is that except where features are removed from browsers, which is comparatively rare, we will have a consistently increasing level of interoperability as we accept changes, meaning that at any time a snapshot of the Editors’ draft should be a stable basis for an improved version of HTML that can be published as an updated version of an HTML Recommendation.
We want HTML to be a specification that authors and implementors can use with ease and confidence. The goal isn’t perfection (which is after all the enemy of good), but rather to make HTML 5.1 better than HTML 5.0 – the best HTML specification until we produce HTML 5.2…
And we want you to feel welcome to participate in improving HTML, for your own purposes and for the good of the Web.
Chaals, Léonie, Ade – chairs
Alex, Arron, Steve, Travis – editors
30 thoughts on “Working on HTML5.1”
Since we can write our own directives, HTML isn’t it useless nowadays:) ?
I reckon we could count them, I know of a few orgs that do it but it’s generally with even tighter restrictions such as a whitelist, I only know a handful of users that have an extension to disable it but again it’s specifically for testing purposes and giggles.
typo in the conclusion :
— but trather to —
Thanks Anthony (fixed) :)
how can i participate?
You can contribute to discussions around HTML issues, or file issues yourself if you know of bugs in the HTML specification.
You can also create a pull request that contains a proposed solution or update to a known issue. If you head to the HTML repo, you’ll find basic information on getting started.
If you have questions, please post them by filing an issue (using the link above). HTH
Will HTML5.1 be a huge update and I’ll have to forget some or most of the things I’ve learned in HTML5, or will it be a smaller update where i just have to learn a few more things?
I didn’t know about html 5.1. Is there a list of potential changes that I can start reading about? Thanks
The changes between each Working Draft can be found in the changes of the HTML5.1 specification.
You can also keep track in real-time through Github, or by following the Twitter accounts mentioned in the Timelines section in the post. HTH.
The change between each working Draft can be found in the change of the HTML5.1.
Any possibility that we can have single HTML standard? for:
Sounds horrible. Why would you want that?
What is expected is like, need a vehicle that should have four wheels to drive in road, wings to fly, two hands to swim in the water.
This is something interesting and something that I was eagerly waiting for. A new version of HTML 5. Great work team.
HTML 5.1 sounds like it is going to be worth having, better than having a single standard for html
I’m so eager about this version, it should be more perfect and convenient
It should be better :)
Okay that´s interesting :)
Waiting for 5.1 to come out..
I think an annual release is a very bad idea. HTML needs to be dependable and I think a speed to market philosophy will negatively effect it. Once the standard is finalized, the browsers will still have to be updated and developers will still have to be trained.
Comments are closed.