-webkit-HTML5

Apple took some of their Safari Technology Demos from their developer site and published them at http://www.apple.com/html5/ as an “HTML5 Showcase”. Christopher Blizzard’s blog post about the subject says almost everything I’d have to say, so please read Blizzard’s post. I’m posting just my diffs here.

I was reading the comments on Blizzard’s post after the post had been Fireballed and the Apple fans had done their thing in the comments. I also read Gruber’s follow-ups on Daring Fireball. There are two things I feel like counter-commenting on, even though I know I’m tilting at windmills.

Safari or Standards?

First, I agree with the pro-Apple commenters who observe that the Apple showcase isn’t about the world thinking that Apple isn’t supporting HTML5 but it is about Flash. The gap between perception and reality that Mozilla needs to close and the gap between perception and reality that Apple needs to close are different. The gap Apple needs to close is the gap between the Adobe and pundit-spun perception that you need Adobe’s runtime to do cool things inside a browser window and the reality that you can do those cool things (specifically on the iPad) in Apple’s runtime.

I’m all for having that perception gap closed, although I’d prefer generalizing the message to being that you can do the cool things natively in browsers in general.

Still, Apple’s showcase isn’t offensive because they are demoing Safari features. The Apple fans who say it’s OK to demo Safari features seem to miss the point that the criticism is not about demoing Safari but about pitching the demos as standards demos. The showcase is at apple.com/html5/. It’s not at apple.com/safari/. (On the developer site the demos were correctly titled as Safari Techonology Demos.) The whole point of standards is interoperability, so blocking other browsers is a huge mismatch to the text the copywriter wrote. (The text is pretty awesome, by the way. I wish it had been coupled with demos that didn’t contradict the pitch.) Furthermore, blocking other browsers is particularly offensive when considered against the backdrop of Browser Wars 1.0.

Furthermore, the demos have very, very little to do with HTML5, the spec. Apple seems to be using HTML5 as a buzzword that means “doesn’t use Flash”. The demos mostly showcase WebKit-specific additions to CSS.

With that rambling out of the way, I’m finally getting to what I wanted to write about:

It’s Not Just Browser Sniffing!

What bothers me the most about the reactions of Apple fans is the bogus method of quickly judging if other browser would be as capable as Safari had Apple not put the browser sniffer in place. I’m not surprised that people who have a sports fan-like cheering relationship with Apple would make this mistake, but I’m saddened that Gruber also made the mistake of drawing conclusions by spoofing the UA string in other browsers and then trying the tests. Even in response to Haavard’s post that made the points that I’ll make below but in fewer words.

The demos have three levels of obstacles for non-Safari browsers even if the other browsers implemented the HTML5 features being demoed (only video and audio; the rest is CSS!) and implemented the proposed CSS features once standardized:

1. The browser sniffing

2. Demonstrating HTML5 media features with patent-encumbered codecs.

3. Vendor prefixes.

There has been ample discussion about the ills of the licensing of MPEG codecs. I’m not going to discuss the sniffing or the patent-encumbered codecs further.

As mentioned above, apart from the HTML5 video and audio features, the demos focus on demoing not HTML5 but Apple’s proposed extensions to CSS some or all of which might become standards down the road. But how is this any different from HTML5 not being a “finished” standard yet?

Vendor prefixes.

Suppose you see an Opera demo of HTML5 forms. HTML5 isn’t “finished” yet, but Opera implements HTML5 forms without any vendor prefixes, so when another browser implements the features, the demos can start working in that browser.

But that’s not how things work with CSS. When someone implements an extension to CSS, the implementor is supposed to use a vendor prefix. Instead of calling it foo, it’s called -moz-foo if Mozilla made it up, -webkit-foo if Safari or Chrome developers made it up, -o-foo if Opera developers made it up or -ms-foo if IE developers made it up. Not only are you supposed to use a vendor prefix for stuff you make up but you are also supposed to use a vendor prefix when implementing proposals by the CSS Working Group itself until the spec is far along enough on the standardization track. A variant of the same convention is used for DOM methods and properties, too (mozFoo()).

This means that even when there’s multivendor consensus that a proposed CSS feature will become standard, until we get there, the same feature will be implemented with different vendor prefixes in different browsers. CSS Transitions and 2D Transforms are supported in Opera and Firefox (transitions not in Firefox 3.6 yet). However, to use them, it’s not enough to use the -webkit- variants. You need to use -o- and -moz- variants, too. (At the time of writing, the style sheet for my own site repeats transition-related CSS properties using 3 different prefixes.)

It follows that if you have a demo (or, worse, a real-world non-demo site!) that uses the -webkit- prefix, the feature won’t work in other browsers even if they supported the feature with their own vendor prefixes. Worse, when the feature advances towards being a standard and the vendor prefixes are dropped, the -webkit- prefix won’t work in browsers that just support the unprefixed standardized syntax. (In case it’s not clear, Apple’s demos use only the -webkit- prefix in various places even though the typography demo makes an effort to support other browser engines, too.) Thus, even if Apple’s proposals became standards and you had a fully compliant browser, the demos wouldn’t work simply by spoofing the user agent string. This problem isn’t limited to Apple’s demos. It applies to “HTML5” demos more generally.

So if the vendor prefix convention is a problem, does the convention make any sense? Should Apple have implemented the proposed CSS properties without the prefix like they minted <canvas> without a prefix? It turns out that the prefixes do serve a purpose. They buy time for peer review in the CSS WG so that the Web isn’t stuck whatever flawed design decisions the first shipped implementation had. Remember that the first shipped implementation may have been developed in stealth mode without peer review during the development process (which is in itself a problem but it’s hard to make companies not do stuff in the stealth mode ever). Even <canvas> changed as result of peer review and Apple had to introduce a special mode in WebKit for compatibility with legacy Dashboard widgets.

If a prefix is needed, why not have a common “experimental” prefix for all vendors? The IETF has had a common experimental prefix (x-) for years, and experience shows that having a common experimental prefix defeats standardization. The prefix gets stuck and we are back to the situation of getting stuck to whatever the first proposal happens to be like.

But isn’t this vendor prefix convention anti-competitive? What if you want to enter the market but the existing content assumes a fixed set of prefixes? This is the situation Microsoft is facing. Microsoft had decided to implement -webkit-text-size-adjust, but both Web authors and Apple staff objected, so Microsoft backed off. I think vendor prefixes have anti-competitive potential and vendors should be free to implement each other’s prefixes in order to address market situations even if doing so would defeat the point of the prefix and standardization.

So what can be done? First, I think the CSS WG needs to adjust its policy on vendor prefixes to remove the prefix much sooner than under the current policy. It’s bad for the prefixes to stick around for multiple browser release cycles. Second, if you are making a demo that relies on vendor prefixes and you are pitching it as a standards demo, you are doing it wrong.

Finally, I should also point out that not all of Apple’s proposals are as clearly on the standards track as CSS Transitions and 2D Transforms. The blurring and masking effects have a competing proposal from Mozilla: using SVG filters on HTML content. (It’s great that Apple is proposing stuff for standardization. I am in no way criticizing Apple for coming up with cool stuff and proposing it for standardization. Proposing it for standardization early is good. It’s a bit early to demo those things as already being standards, though.)

Epilog: What about Chrome?

The above explains why Apple’s demos don’t work in Firefox, Opera or IE even with UA spoofing even when the features are implemented. (Aside: I believe all the effects Apple demoed are achievable in Firefox 4 with WebGL enabled. Yeah, yeah, I know that talking about unreleased software is like talking about Flash 10.1. Most effects would be achievable in Firefox 3.6, too, though. Yeah, I know this claim would be more credible if I backed it up with demos, but I’m busy.) But why doesn’t the “VR” demo work in Chrome, as a number of people have observed? Chrome supports the -webkit- prefix after all and uses the same WebKit source code as Safari.

This is because the VR demo uses Apple-proposed CSS 3D Transforms to map the photos onto the six sides of a cube as opposed to using WebGL, which is being implemented in Firefox, Chrome and Safari but isn’t enabled by default in any of them, yet. 3D Transforms need non-trivial support from the environment WebKit builds on. It turns out that it’s not just Chrome lacking those bits: the demo doesn’t work in Safari, either, on Leopard or Windows. (My guess is that the feature relies on Core Animation surfaces, but I haven’t verified this guess.) So much for just downloading Safari.