Does Your Browser Really Support HTML5 and CSS3?

I like reading rants. And by rants, I mean well-thought, researched, articulate arguments that are the result of a festering pool of frustration finally shooting out and being channeled into something constructive. Not the rants you might find on bathroom stalls.

Thanks to the Twitters I came across a blog with a two-part rant about HTML5 and browsers. It echoes rants I’ve read or written 10 years ago, the result of chafing against browser makers and developers buying into standards too soon, chastising each other based on unfounded data, and blind faith in one option over another despite overwhelming data to the contrary.

I watched people say HotJava would save us from Mosaic, Netscape would save us from HotJava, NetShark from Netscape, Internet Explorer from the internet, Mozilla from Internet Explorer, Opera from everyone, Firefox from Mozilla, Safari from ourselves, Chrome from whatever is left, and so on. It’s been done, we’re looping back through. Examples other than browsers? HTML 3 from HTML 2, HTML 4 from HTML 3, ISO HTML from something, XHTML 1 from HTML 4; JSSS from font tags, CSS from font tags, CSS 2 from CSS 1, CSS 3 from communists; PNG from UNISYS; MNG from animated GIF; Flash from Shockwave, Silverlight from Flash, HTML5 (and CSS3 and JavaScript) from Flash; VRML from boring pages; Quicktime from AVI, Windows Media from Quicktime, YouTube from Windows Media, Ogg Theora from YouTube, H.264 from Theora, VP8 (WebM) from H.264. And on…

The point of all that comes down to the fact that things change. Quickly. Especially on the web. Relying on an unfinished spec (HTML5) to build your browser support and/or code your pages is full of risk, risk that is passed on to end users and clients. There is a tangible cost to go back and fix things that short-sighted developers implemented, whether by making corporate Help Desks do company-wide upgrades (or making the poor kid down the street do it for smaller companies) or by making clients pay to fix something on their sites that should never have been implemented to begin with.

Cue the rant. Lars Gunther has written a piece that breaks down actual browser support versus marketing statements of browser support, taking Webkit in particular to task (No browser supports HTML5 yet. Part 1. The rant.). His points ring true (even though he also discusses CSS3), especially if you have been in the web world long enough to witness the browser wars from the 90s. Some key statements:

…[O]nce someone has started to claim support for a feature, even though that support is half baked and incomplete, everyone else has to answer in kind, and claim support even when their implementations are equally half-baked. Or even worse, rush out such half baked implementations to the market to show everyone that they are also a leader.

We’ve seen this in the half-baked support for PNG images in Internet Explorer for years. We’ve already experienced this abrupt deployment of incomplete features for a decade, and now Apple happens to be the company doing this via Webkit. It was terrible when Microsoft did it, but somehow it’s not raising any hackles this time out.

…[W]e tend to put up demos of new cool technologies that are not really examples of best practice, e.g. even though transformations and transitions work in the latest versions of Firefox and Opera, many demos use the webkit prefix only.

Given how many young and/or inexperienced developers still get by with the thieving of source code, add in some prior experience with IE-specific hacks, and we are running the risk of developers implementing features incorrectly, even when other browsers may have supported a spec for years.

In part 2 of the rant (No browser supports HTML5 yet. Part 2. Technology.), the author proceeds to back up his points with some data. He pulls out three aspects of HTML5 that Safari and Chrome (as examples) both claim to support but really do not.

The world of HTML forms has opened up a lot in HTML5, allowing many different types of input elements, for example. In addition, accessibility is built into the spec for these elements from the start:

At the moment neither Webkit nor Gecko (nor Opera) is nowhere near having a complete HTML5 web forms support. They all lack some features and they all lack accessibility.

Sectioning elements, such as the oft-confused section and article elements, need to be accessible via the DOM to more than just styling:

…[S]ectioning elements affect document outline and that should in turn be exposed to seeing users through varying sizes on the headings and to non-sighted users through their assistive technologies. […] Being able to style a sectioning element is actually a bullshit claim. HTML5 mandates that one should be able to style any unknown element. That is, a browser vendor could claim that they support the , and elements, since according to HTML5, they should!

The hgroup and nav elements were designed to hide subtitles from the DOM outline and to provide greater accessibility for accessing navigation, respectively. Their functions are pretty clearly laid out in the specification.

There is no browser on the market that supports these behaviors. Indeed, to my knowledge, no browser even has begun working in earnest on this.

These are each examples that one or another browser vendor claims it supports, when it really does not.

As I have done for prior specifications over many years, all I can do is remind people not to get caught up in the marketing hype and the gee-whiz factor of the technology. Understanding your users, their available browser features, and the business cases for implementing a particular technology are the better methods for guiding how you should build for the web. If you want to play with the cool new gadgets and features, do it on your own time, don’t make your users or clients pay for it.