Forwards
In recent weeks I contacted around 40 people, a cross section of those who have banged away at, or banged on about, HTML5. I asked them for their perspectives on HTML5 becoming a W3C Recommendation. Below are the words of the 28 people who responded, pretty much in the order they hit my inbox:
HTML5 is a W3C Recommendation, what do you think?
HTML began 25 years ago to provide content and links, the initial flesh and bones of the web. HTML5 is still the basis of a web of links and content, but it is now also the user interface part of an entire computing platorm. Now every web page can be programmed like a computer. That is a huge change, and we can only imagine what will be deployed in the future on top of the Open Web Platform.
I showed up at the W3C in 2007 to do three things: chew bubblegum, help get a new HTML spec to Recommendation, and kick ass. We’re now near the end of 2014, HTML5 has finally reached Rec, and I’m all out of bubblegum.
The publication of the spec reflects a formidable success at finally gaining consensus. This is always difficult, but made more so in a group that could not move forward and at one point due to to infighting and the inability to do exactly what Tim Berners-Lee suggested we do in his remarks at yesterday’s W3C 20th Anniversary: “Sacrifice your own way of thinking.” So we’ve made big progress on that front. Insofar as the spec itself – as with all specifications – some good, some bad, some intolerable, some ridiculous. In the end it doesn’t matter, really, because it is not always what is specified that is pragmatic. That which is implemented and understood first become the languages, tools and techniques we actually put to use.
Again, my most sincere thanks for including me – each step forward in my work is a step forward in my enjoyment of life no matter my personal circumstance.
The path to HTML5 has been more than a little rocky, and if the road to get to this point isn’t littered with dead bodies, there are some walking wounded among the specification participants.
But none of the interesting times spent working on this spec matters once HTML5 is officially done, and launched. All that matters is we have something we can all live with, being implemented in all our favorite tools, and providing us so much more than what we had before the effort started. That’s the win, the gold star, and the only reward so many hard working people will get for their effort with this spec: the web is a better, richer place.
So thank you hard working people, in the W3C and out. Thank you for not giving up, and seeing it to the end.
All systems that are going to improve must “breathe”; they must undergo periods of expansion and consolidation. HTML5 represents important consolidation for the web platform and I’m glad that the W3C is putting a bow on it and getting broad agreement about what it “is”.
This isn’t to say we’re done; the reason I’ve worked on Web Components in the recent past is to help ensure that the next breath won’t need to be so deep or long. The driver of nearly all progress is iterative improvement. That HTML5’s parsing includes support for custom-element definitions helps ensure that we can democratize the evolution of our shared platform so that when we get around to it, HTML6 can be informed by a vibrant community of extensions that pave a path for new semantics without fighting the language in the interim.
Finally a stable HTML5 specification that authors can develop against, knowing it will not change from one day to the next. And a lot sooner than the 2022 date that was previously mentioned.
There are some really good things in HTML5. The re-think of how the spec works, as a way to take more or less anything that claims to be HTML and produce a DOM is a big step forward. And of course it is aligned with reality, and browsers have worked much harder to align with it than they ever did with HTML4 or 3.2, which makes everyone a winner.
There are things that are not that great. Writing a huge pile of algorithms makes the document very hard to read, and it is *very* big, which in itself is a drawback. Similarly, there are some steps forward for accessibility, and the inclusion of SVG and MathML is a step forward accessibility that should bring other advantages, although there are some problems in the real world that make this less valuable than one could hope.
But the disadvantages are minor compared with the advantage of having a modern spec that is pretty close to what browsers, web pages, and other tools actually work with. It’s high time to publish what is there, although it is important to keep working – the web is a living platform, and while different bits move at very different speeds we have been a bit slow in offering a stable target since XHTML 1.0 was published as the last significant revision of HTML.
@briankardell @stevefaulkner ASK BRIAN’S MOM
— Sylvain Galineau (@sgalineau) October 20, 2014
@stevefaulkner I’m assuming this is @sgalineau‘s quote for HTML5 transitioning to REC :-p “ASK BRIAN’S MOM”. I did, she said “YAY!”.
— вкαя∂εℓℓ (@briankardell) October 20, 2014
I’ve been experimenting with Meteor, recently; a javascript application framework. It returned a curious error just yesterday, when I started the application after editing the master HTML file: ‘Can’t set DOCTYPE here. (Meteor sets for you)’. Five, maybe four years ago this would have been considered highly dictatorial – irresponsible even.
The fact is, HTML5 is now the de facto language of the web. We know that already, so arguably a ‘recommendation’ from on high feels somewhat irrelevant. I see it like this: Together we – the implementers and authors – have embraced and advanced HTML5. We are the tide and the recommendation is the high water mark. It’s nice to see how far we’ve come.
Developing standards is not unlike developing software: you can’t just continue to develop new features – you have to stop from time to time, assess the features that you have, remove those that aren’t working, fix those that have bugs, and release a new version. HTML is such a beast and while it is important to continue its development, it’s also good to have a fixed feature set that people can reference and rely on. So: congratulations to the W3C for getting HTML5 to Recommendation status.
But what does it mean? HTML5 is the basis for a new stable and fully interoperable Web. It lists a feature set that Web developers should be able to rely on in all browsers. Thus, HTML5 is a Recommendation to browser developers to make that interoperability uniform. Find those features that your browser isn’t supporting yet in the list of HTML5 features and implement them (well, yeah: by also looking at the version of that feature in the WHATWG spec, where bugs are fixed and features continue to evolve).
This means, to everyone else: HTML5 is a Recommendation to develop more benchmarks that test the interoperability of the features. There are places like http://html5test.com/ , http://caniuse.com/ , or the W3C’s own test suite, already, but HTML5 is big, so find your favorite features and help make the Recommendation become a real standard.
It’s marvellous that HTML5 has reached this point of maturity, and that accessibility has truly emerged as a core design principle. The inclusion of ARIA puts critical semantic information right where developers need it – at the heart of the HTML specification. Coupled with features that were introduced in HTML5 (like native controls and new structural elements), we’re now in a position to design and build innovative interfaces that are usable by everyone.
This milestone is a time to look to the future as much as to past accomplishments though. As HTML development continues, we need to achieve and maintain a faster and more flexible way of working, without sacrificing the inherent stability and resilience of this open W3C standard.
People hardly remember in what limbo state was (X)HTML in 2007. At the time, I was part of W3C staff. We were struggling and discussing about the best outcome for the future of HTML. WhatWG had started since 2004 to rewrite the lingua franca MarkUp language with a much more implementers oriented specification. Finally W3C rebooted the HTML WG on March 2007.
To see HTML5 being finally released is a huge step for all people of good will participating into this effort. Imagine that. For the first time, we defined a precise algorithm for parsing HTML as it is written on the Web. It means less ambiguity. We got an enriched semantics for authors with a lot better support by browsers than in the past. It means better accessibility. And so many other things.
There will be more struggles in the future. How do we, the Web community altogether, decide to evolve the Web? But, we now have a solid foundation where we can build upon and explore new areas. This is HTML5. Let’s celebrate.
HTML 5.0 isn’t a destination, but rather a long-overdue step on a long journey.
I have mixed feelings about the process, but I’m delighted that HTML5 will be “finished” in 2014. Sure beats 2022. As for the idea that there will be subsequent updates (HTML5.1, HTML5.2, etc.), well, of course there will be. Specifications make more sense to me than the idealistic but somewhat vague idea of HTML as a “living standard.” Living standards are nice, but it’s also nice to be able to say that Browser X fully supports HTML 5.0 (or HTML 5.1, and so on).
Prior to HTML5, HTML did little to ensure consistent implementation across browsers and accessibility features were added late in the cycle without a comprehensive look at accessibility and how accessibility could be added in a way that made it easier for the developer to produce custom accessible applications. The release of HTML5 to recommendation status by the W3C specifies how HTML must be implemented across browsers to ensure consistency.
HTML5 is also the first host language to give authors a comprehensive set of tools to produce accessible custom rich internet applications, through its integration of WAI-ARIA, and accessible rich media to support the blind and visually impaired. These changes leverage the browser to produce cross-platform accessible applications at a dramatically reduced cost over native platforms as the cost of mapping the accessibility information to platform accessibility API services layers is pushed off to the user agent.
In short, HTML5 has established the core plumbing needed for accessibility and browser consistency and the work here can now be carried over and built upon for electronic books, Scalable Vector Graphics, and CSS – the bar has been raised. With the core plumbing in place the greater areas of innovation will now be in accessible graphics, device independent interaction, enhance web application functionality, CSS driven content and navigation, and context aware application infrastructure development.
Finally! w00t!
On the one hand, it doesn’t really matter whether HTML5 is W3C recommendation or not. After all, what really matters to developers is what they can use in browsers today. So, from that perspective, the way the WHATWG views HTML as a “Living Standard” makes a lot of sense.
On the other hand, it’s awfully nice to have some stability in the ever-changing world of web standards and browsers. That’s where the W3C provides balance. They are the yin to the WHATWG’s yang.
HTML5 reaching recommendation status provides a welcome punctuation in the ongoing story of the most important format ever created.
Gosh! It’s not 2022, yet we’re getting HTML5 early! Of course, many web developers know that much of “HTML5” has been ready for a long time in browsers, but it’s important that IT Directors, compliance people and clients know that this is a *stable* standard that reflects what’s in browsers now. With an incredibly active community of developers, browser vendors and spec authors, this is a milestone but emphatically *not* the destination. Onwards, and vive le web!
@html5_yoda Don’t speak too soon. I’m still here. @stevefaulkner @html5doctor
— Vader (@html5_vader) October 24, 2014
Many people do not realize that agreement and adoption happens on a continuum: Early adopters pay a price to do it. As things settle down, waves of increasingly less knowledgeable or risk-averse adopters join in, and all the while we are honing the proposal, and implementations. Given this, for many of us, promotion of HTML 5 to REC will seem like a non-event – a kind of statement of the obvious. At some level, it is: A recommendation, at its best, is a statement of agreement about already at that point *is* standard, not what should be. The value in REC is setting of a goal more than the eventual arrival. It’s true that there is a long tail of developers who are unwilling (or even unable) adopt until something reaches this level of maturity officially, and for them, this move will be a very big deal indeed. For the rest of us, I’d suggest that this is the time to appreciate the many hurdles crossed and the long struggles to arrive to this point – step back, assess and examine the things that made it much harder and more frustrating than it should have been at times and the ways that we can improve it all dramatically by changing the model, involving developers, building up and letting us #extendthewebforward.
I am very pleased to see the World Wide Web Consortium release a new version of html in a specification that is not going to change overnight. Even if a frozen state implies imperfections, I don’t see that as a problem if errata are correctly and timely dealt with. That’s the mistake the W3C made years ago not maintaining HTML4 and I think they got the message. A frozen html5 was needed by some industries out there that just cannot cope with living standards. Some of our partners in Standardization, like IDPF or ISO, also need to refer to a given version of our specifications. The world of our users is very different from the world of our implementers and we neglected some of them. The W3C has implemented considerable changes to its process to achieve that html5 release. Some came easily, some were heavily discussed and triggered a lot of noise. After a start based on a rather heavy process, the HTML WG came back to more pragmatism. I see that as a mark of maturity. I now look forward to the modularization of html, the specification looking too heavy to me to remain as is in the future.
HTML5! HTML5! HTML5! — Chewbacca (@HTML5_Chewbacca) October 23, 2014
The relatively popular opposition between living standards and snapshots is a false dichotomy. More importantly, we don’t need to choose: as a community we have vast amounts of experience with a processes that marry continuous updates, testing, and periodic releases as that is a common and proven way of producing software.
Standards are similar to software in more ways than one, yet we have long been remiss in applying our knowledge of the latter to the former. This needs to change.
HTML5 exhibits many of the travails of large software projects. Is it perfect? No. Is it complete? Not in the least. But we’re now in a good place to move on to a new phase in which we push open standards towards a saner, happier open source-like model. I for one welcome this bright future.
Milestones are an important part of any journey, and this is a significant milestone. I’m glad to see us reach this one, and I’m looking forward to seeing what comes as we approach the next.
It will be great to finally have a version of HTML that can be used as a standard to work from. Although some of us are lucky enough to work in an environment where we can happily use experimental and non-standard HTML features, there are others for whom standards are very important – perhaps even mandatory – and having one for HTML allows them to move up a step to something stable. This can only be a good thing.
In the beginning it was said that HTML5 would not be “ready” until 2022, but here we are at the end of 2014 and we’re nearly there. A lot of hard work by a lot of different people – in the W3C, WHATWG, and outside – has gone into getting the specification this far, and long may it continue to evolve.
HTML5 going to Rec is a significant milestone and something of significant value for society. It will be the first time we have an actual (royalty) free and open standard that describes how core parts of the Web Platform *actually work*. Despite the success of the Web, previous attempts to standardize HTML were not very successful, forcing browser vendors to reverse engineer each others browsers. This led to many years of stagnation in the platforms.
With HTML, we actually have a more realistic understanding of how the platform works. And with the IPR assurance that comes from HTML5 going to Rec, it means that everyone will be free to implement what is in the HTML5 specification without fear of legal repercussion from other W3C members who were part of the HTML WG. We are talking about big big big companies with large patent portfolios potentially worth millions, which they are essentially giving to the commons. Thanks, Apple, Google, Microsoft, IBM, etc.! you is good peoples.
It is time for HTML5 to graduate. It seems to me that we’ve done a too good job hyping HTML5 whilst we created and implemented it in browsers and we moved fast and broke a lot of things. You’d be hard pushed to find “HTML5 solutions” out there using plain vanilla code and not rely on many abstractions, polyfills and libraries. Even worse, many tell you flat out to use a certain browser – a massive mistake we already made with IE6 in the past. In the enterprise world, none of these “fixes” are applicable without certification or auditing and even HTML5 wasn’t really an option until it is a recommendation.
It will be an interesting talk to convince people to upgrade all the old systems that rely on bespoke browser technology of 1999 and move towards a multi-browser world. Having a recommendation sanctified by the W3C is a great stake in the ground to work from.
I think the W3C HTML5 Recommendation is important in the sense that some very big companies have committed (or are about to commit) to exclude the important Web functionality described by the W3C HTML5 Recommendation (which is a modified snapshot of WHATWG HTML) from patent aggression. However, I think the W3C HTML5 Recommendation should not be oversold as being useful for purposes other than a reference point under the W3C Patent Policy. In particular, the “Plan 2014” process arrangement that allowed HTML5 to proceed to Recommendation with relatively sparse test coverage means that it’s quite possible that there are areas of the specification that developers shouldn’t be relying on in case those areas of the specification turn out to be wrong due to inadequate test coverage.
In general, it’s a bad idea for both browser developers and Web developers to read old specification snapshots. Browser developers should generally read Editor’s Drafts instead of Recommendation snapshots and test suites should also track the most recent spec edits instead of reflecting snapshots whose bugs may already have been fixed in more recent edits. For Web developers it often makes sense to refer to Web developer-targeted documentation such as Mozilla Developer Network or Can I Use and, when those fail, also refer to Editor’s Drafts of the relevant specifications.
The cost of getting to this snapshot has been very high, unfortunately. It’s very sad that the HTML WG ended up driving away many of the people who had contributed to the HTML5 effort at the WHATWG and had come over to the HTML WG when the new HTML WG was established in 2007 to bring the WHATWG’s work on HTML5 into the W3C. I hope the divergence between WHATWG HTML and W3C HTML won’t be permanent.
One of the most pleasing aspects of the W3C’s work on HTML 5 has been the renewed commitment to testing, through initiatives such as Test the Web Forward and the web-platform-tests open source project. Implementation differences have long been a source of frustration for web developers, and the creation of cross-browser testsuites for the web platform is the best way to eliminate them in the future.
Just because HTML 5 has now reached Recommendation status, this testing work does not stop. Although HTML now has a more substantial testsuite than at any time in the past, we know that there are large areas that still have poor test coverage. Rectifying this is an ongoing project, and one where all web developers can make an invaluable contribution by submitting tests to web-platform-tests whenever they encounter incompatibilities between different browsers.
HTML5 is an important step forward for browser interoperability. When HTML 4.01 was published back in 1999, it said “Since user agents may vary in how they handle error conditions, authors and users must not rely on specific error recovery behavior.” This meant that the behaviour of malformed HTML was undefined despite a huge percentage of pages being malformed (some deliberately for better performance in some browsers). Back them, few would have believed that it was possible to write down a common algorithm for parsing HTML and then get all the popular browser engines to adopt and implement it. But HTML5 did that. And it did so much more. The HTML5 Recommendation brought a level of preciseness to the core pieces of the web that we didn’t have before.
Is HTML5 finished? Is it perfect? No, it’s a software project and it is a work in progress as is the whole web. The web keeps growing, keeps adding new capabilities, and keeps getting better. But shipping is a feature and the web community has spent the last couple of years stabilising and scoping the HTML5 specification. This is an important stabilisation milestone on the way to an even better future.
The HTML5 parsing steps and I become acquainted long before I joined the editor team; I ran the spec algorithm on a particular input that was exploiting a defect in IE to confirm both that 1) if IE had only implemented the spec this wouldn’t be a problem and that 2) the HTML5 spec was going to take more than a mild investment to fully understand. Boy, was that an understatement.
HTML5 changed a lot of things. It redefined the expectations of what degree of detail is necessary to achieve broad interop. It brought together and standardized diverse new capabilities like media and canvas. It demystified name lookup on the window. It even provided all those who had the pleasure of working with it a great deal of </sarcasm>. Literally.
Getting this spec to Rec is a major accomplishment for so many people. While HTML’s journey will surely continue on, it’s great to pause and appreciate this significant milestone. I’ve had a wonderful time getting to know the many amazing, talented, and persistent people behind the scenes making it all happen. Thanks and congratulations!
To keep the web truly open we need to protect our multi-browser supported web. This is an epic milestone in the hard work for an interoperable web platform. To be continued!
Afterwards
Mike[tm] Smith, – W3C HTML Working Group Assistant Remedy Engineer, relaxing (off duty) in front of the HTML World Standard sign.
Work continues apace on HTML at the W3C and WHATWG and any place where people are working on HTML and the Open Web Platform. HTML5 to REC is a promise to the Open Web Platform. Now there is no excuse, we can all officially say goodbye to HTML 4 and XHTML 1.1.
…and right now, RIGHT NOW, its time to KICK OUT THE JAMS MOTHERFUCKER!
– MC5
The ride to 5 originally appeared on HTML5 Doctor on October 28, 2014.