I attended two in-depth sessions on HTML5 at Oredev 2010 last week, which completely changed my perspective at it. After watching Giorgio Sardo present Microsoft’s plans for HTML5 and Robert Nyman present different HTML5 APIs, I feel that we’re moving ahead in technology but fear that we’re going back to the browser incompatibility horrors of a decade ago.
Microsoft is committed to HTML5
Giorgio Sardo, a senior technical evangelist at Microsoft, started by saying that “Microsoft is committed to HTML5, and this is not a marketing message”. On the many compatibility tests out there that measured Microsoft’s browser support for the new standards well below the competitors, he said that they want to ensure that “HTML5 needs to be done the right way”. Sardo compared that to IE6, which was “built listening to developers”, bringing many features that were not standard or “ready to be standardised”, and now causing lots of compatibility problems.
Sardo insisted that IE9 won’t have any HTML5 “specific markup that works only in IE”, and that they want to wait for specifications to be standardised before supporting them in IE9. That relates to about 150 specifications that are under development by W3C and ECMA working groups. “HTML5 is one of them, but the others are important as well – for example SVG. Some are already standardised, some are working drafts and recommendations”, said Sardo, adding that Microsoft doesn’t agree with all of the specifications. For example, they will not implement WebSQL, but prefer the IndexedDb specification.
But HTML5 isn’t just HTML5
Robert Nyman, an independent consultant, said that HTML5 is a “collection term for all the new things happening on the web“, and comes packed with different APIs. These different APIs are what Sardo referred as 150 specifications. Having the two presenters refer to HTML5 with completely different meanings, the former looking at it as just one of 150 specifications and the latter looking at it as an umbrella for all those APIs, wasn’t really encouraging.
Both presentations gave me a bit of a mixed message. Looking at the examples from a purely developer perspective, I see how these new APIs could help me build better web applications easier.
- Semantic elements such as header/navigation/caption will allow search engines and smart devices to make better use of web content and improve accessibility.
- @media queries in CSS3 will make it easier to support different resolutions
- JSon lambda expressions and the new object model will standardise some commonly needed functionality and could reduce our reliance on third party libraries and frameworks.
- video tag will provide better control over video playback (but unfortunately not compatibility – see below)
- Cross-document messages should allow cross-domain communication in a controlled way and help us build more integrated applications with improved security
- web workers should allow us to create more responsive applications by pushing processing to background threads
- HTML cache manifests should provide us with better ways to handle network disruptions and even create offline apps
- Websockets could reduce our reliance on third party plugins for data push from servers to browsers
- History API should allow us to better integrate AJAX into browser controls and provide users with a better experience
- WebGL could bring 3D graphics capabilities to browser applications and reduce our reliance on third party plugins
The big promise of most of these new APIs, for me, is to reduce our reliance on Flash, Silverlight, JQuery and other third party toolkits and browser plugins and standardise functionality that many applications need. But I’m worried that they will just replace that problem with another one and make web applications even more reliant on a different kind of third party libraries.
Will we really be less reliant on frameworks?
Sardo’s statement on Microsoft being committed to HTML5 is encouraging, but I’m not really sure what they are committed to. Is it just the list of tags and the new HTML5 document object model, or does that commitment extend to the functionality that all those new shiny APIs will support? Some of these specifications aren’t really going to materalise in browsers anytime soon, and some don’t seem to be up to the task. “IndexedDb is going to happen but it’s going to take some time“, said Nyman. Among other things, he showcased drag and drop support which was, according to him, reverse engineered into a specification from IE features and it is a “fucking disaster”.
The slides with code in both presentations reminded me very much of the web applications I was developing 10 years ago, with so much browser incompatibility that we wasted an enormous amount of time tweaking HTML and JavaScript to work with particular browser versions and sub-versions. At that time we only had to write for a few versions of Netscape and IE – the situation now is much more complex. Fair enough, there won’t be any browser specific tags, but both presenters showed a ton of compatibility related code. For example, although video is a standardised tag, different browsers support different formats. Even within a format they support different codecs. Checking for video codec and format compatibility by specification returns ‘no’, ‘maybe’ and ‘probably’, which doesn’t really sound encouraging. And most people releasing apps with HTML5 code will have to provide fallback on other technologies for older browsers. The code that both presenters showed for video playback was more complex that the tag for embedding Flash which I use now. Speaking about the video tag, Nyman said “the idea is to make it better, but I’m semi-hopeful”.
I guess a large part of my gut-feel about this is caused by the fact that there are 150+ specifications about “all the new things happening on the web”, as Nyman called it. If anyone came to me with 150 specifications and asked me to lead a project to implement that I’d throw him out straight away. In order to get the compatibility across browsers, that project has to succeed not once, but several times in different companies and opensource communities. The fact that they won’t all try to implement the same specifications makes it even more confusing. For example, Nyman said that WebSQL is in supported in Webkit and Opera, but it is not going into Firefox and IE, which will probably implement IndexedDb for storage.
A possible solution for this might be programming against third party libraries that will provide backward compatibility and cross-browser functionality, so I wouldn’t be surprised if web development becomes even more reliant on various opensource frameworks. Nyman and Sardo already mentioned a few:
- explorercanvas provides basic canvas support for IE8 with VML
- Raphaël javascript library uses svg or vml for graphics depending on browser features
- visitmix.com/lab has a plugin to export from Adobe Illustrator to canvas format
To end this on a more positive note, here are some nice links from both presentations that showcase new HTML5 features or libraries:
|
|
“Having the two presenters refer to HTML5 with completely different meanings, the former looking at it as just one of 150 specifications and the latter looking at it as an umbrella for all those APIs, wasn’t really encouraging”
I watched Robert presentation and I believe our message was quite consistent and similar. In my presentation I explicitly mentioned that “HTML5″ today is used as an umbrella term to refer to HTML5, CSS3, SVG, WebApps, ECMA Script…As a developer, I believe it’s important to realize that these are very different specifications…that all work together with the same goal: provide a solid and interoperable framework to web developers. For instance, you saw how CSS3 and SVG and HTML can work very smoothly together.
“Sardo’s statement on Microsoft being committed to HTML5 is encouraging, but I’m not really sure what they are committed to. Is it just the list of tags and the new HTML5 document object model, or does that commitment extend to the functionality that all those new shiny APIs will support”
If it wasn’t clear, Microsoft is not committed only to the HTML5 document. We are committed to the broader set of standards. As a matter of fact, we are partecipating to several Working Groups and documents (inside the WebApps WG, SVG WG, CSS WG…) and submitting new specifications to complement what’s already there. Robert showed the capabilities of other spec (for instance, Web Workers or Sockets or GeoLocation) – to me it’s encouraging to think that one day we will be able to code with these “just from the browser”. And I’m confident that as the specs goes to Recommendation status, their implementations will be interoperable.
“I feel that we’re moving ahead in technology but fear that we’re going back to the browser incompatibility horrors of a decade ago.”
We share the same goal of W3C: making the web platform easy for web developers, build strong specifications that can be implemented interoperably and lead to “same markup” result. When it comes to standards, we are succesful only if all browsers (or other implementors) provide an interoperable version of the APIs. That’s why Microsoft has been investing so much (budget, time, people, …) in the W3C. I talked more in depth about some of the work that is happening behind the scenes with W3C here: http://bit.ly/9yTyI0
I really hope we will not get ther again.
“Checking for video codec and format compatibility by specification returns ‘no’, ‘maybe’ and ‘probably’, which doesn’t really sound encouraging.”
Personally I don’t care about the codec, I just hope that one day all browsers will support at least one common codec. And we will do as much as we can to make this happen.
Eheh…I see your point. I think the UA are just very “modest” in dealing with codecs
Btw, thanks for your feedback – I had a great time at Oredev!
Giorgio, Sr. Technical Evangelist, Microsoft Corp
Shouldn’t standards be emergent, not pre-defined?
When you try to create the standard before the implementation, you can have a long delay before useful implementations appear, you can create standards that cannot actually be implemented (HLA), and you can end up with standards that serve no practical need or satisfy a real demand (XHTML 2).
Some of the most end-user visible innovation in the past few years has come from a new browser war: canvas (Apple), XMLHttpRequest (Microsoft OWA), input range (Safari’s RSS reader thingie), and the video element (Firefox). These came from the proprietary level on up, not from the standards tower dropping down. The new “standards” were forged by looking at the past individual implementations, saying “hey that’s a good idea,” smoothing over the differences, and implementing breaking changes gradually in a lock step fashion.
IE6 wasn’t a problem because they listened to developers when writing it, it’s because they *stopped listening* for *years*, creating a browser monoculture where there was no innovation. When innovation started happening again, you had to (1) break the monoculture in order to light a candle under Microsoft so that they would work on IE again and (2) break years of dependency on the old “standard” which proved very difficult.
A standard should be a least common denominator that smooths over the differences in implementations, a pidgin language that works across all of them, not a bunch of Lowth-style prescriptive rules.
But, I must say, a lot of people think my views on this are kind of crazy =) Interesting post!
Thanks for the write-up, it’s very good to read well-articulated responses to presentations!
I think they way I see it, it’s not like you have to use everything that’s new. It’s rather that a lot of technologies, approaches and APis are emerging now, and some will cater to some peoples’ needs, where others will help someone else out.
Hopefully, it’s all about options and having lots of different ways to accomplish things.
I think for some time you will need dependency on third party libraries and so-called polyfills, especially if you want to support older web browsers. But then again, on the web, we will never have a state where every web browser and device works the same way.
So I guess it’s about picking your battles, but also being willing to offer a basic, working-but-not-so-shiny version to older web browsers while giving it all in one consistent manner to newer ones.
Good luck, and feel free to contact me if you want to talk more!