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.
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:
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.
Spoofing the UA string is useless for drawing conclusions about the capabilities of Firefox, Opera or IE, because the demos use WebKit vendor prefixes.
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:
The browser sniffing
Demonstrating HTML5 media features with patent-encumbered codecs.
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?
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,
if Safari or Chrome developers made it up,
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
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
variants. You need to use
variants, too. (At the time of writing, the style sheet for my own
site repeats transition-related CSS properties using 3 different
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
-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
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
authors and Apple
staff objected, so Microsoft backed off. I think vendor prefixes
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.)
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.