
Webkit on Left, Every Goddamn Thing Else On Right
HTML5 is… concerning to me. Now, don’t get me wrong. I’m not cheerleading rickety old proprietary technologies like Flash just to be contrary or out of a misplaced sense of nostalgia, and I’m probably horribly wrong about a number of things (most of my time spent thinking about this topic has been while very drunk around web developers), but there are a number of clear problems with HTML5 as it stands today that trouble me and make me wonder whether the big step forward in internet development is accompanied by two steps backward…
Browser Compatibility
Everything renders differently on every browser. Just ask some poor overworked sap who had to make his site play nice with The Browser That Can Not Die. The thing that worries me, though, is that people are developing for specific browsers again. For example, take this demonstration page by Louis Harboe, which skillfully recreates a number of iOS icons in pure HTML5. It’s an impressive feat and looks great, but it is described as “Viewed best in Safari 5 or Google Chrome”, and with good reason: when viewed in any non-Webkit browser, the whole thing falls apart dramatically, with strangely consistent results. With all respect to Louis, his page has been built specifically for Webkit. It lacks universal compatibility – or at the least, graceful degradation – across browsers and devices which, if I’m not mistaken, is at least part of the reason why HTML5 began development in the first place!
I’m concerned that this practice will become more widespread – pages will be designed for specific browsers as opposed to trying to cover as much ground as possible. I remember back in 1997 or so I’d see pages that recommended they be viewed in IE6 at 1024×768. If pages start using tricks that only work on specific browsers, then, well, have we really gone that far since then?
Streaming Media and the <video> Tag

Round 1. FIGHT!
The <video> tag, much like communism and Casual Friday, is a great idea on paper. Let’s offload the rendering and streaming of video content to the browser instead of Flash! That way all browsers can handle it and we don’t have to deal with (ugh) Quicktime to do such video! And it would have worked so well, too, were it not for one little hurdle… compression codecs.
H.264 is an utterly amazing codec that provides clear, crisp visuals at extremely small file sizes, making it ideal for the web. However, it isn’t free, and as a result Mozilla pitched a fit and outright refused to support it, pointing people towards Google’s free-but-inferior WebM codec.
(Of course, the licensing problems on the browser side could be largely avoided by loading codecs from the Operating System, but then Linux would still be up the creek. But then, when isn’t Linux up the creek over something non-free?)
The end result is that web developers who want to deliver a proper HTML5 experience have to set up each video three times – a H.264 Flash player, a H.264 <video> player, and a WebM <video> player. Ooooor they could just go “screw it” and just stick with Flash, like pretty much every non-Youtube site seems to be doing.
So what’s the end result of all this? HTML5 was created to try and get away from browser-centric hacks and ancient plugins, and yet people are still using them in HTML5. It’s too early and much too hasty to consider a failure, but from the perspective of someone on the sidelines, it sure seems to be kicking a lot of own-goals.

Inflammatory!
From looking at the source code at the iOS with CSS page I can see it’s littered with webkit specific styles:
-webkit-border-top-right-radius: 80px 50px;
-webkit-border-bottom-right-radius: 80px 50px;
-moz-transform: translate(0, -2px);
-webkit-transform: translate(0, -2px);
-o-transform: translate(0, -2px);
transform: translate(0, -2px);
-webkit-box-shadow: 1px 3px 3px rgba(0,0,0,0.2);
So in this case we’re looking at CSS3, a spec which isn’t yet complete so browser vendors are using their own specific implementations until it’s been finished.
Saying that it’s good practise to reference all browser specific CSS 3 implementations, then also replicate the styles in standard CSS3. So that when the spec is complete, the code will work in browsers supporting the final spec.
If the developer had done this, the page would most likely work with all newer browsers.