graphicpush

Thoughts on branding, design, writing and life by Kevin Potts. Established 2003.

Apple and HTML5: Less Than Half the Story

With the launch of its “HTML5 Showcase”, Apple has tried very hard to demonstrate that HTML5 is a big deal right now. Despite locking out and dismissing comparable browsers, heavy reliance on CSS3 and JS, having a nasty anti-Flash undertone, leaving no mention of real-world support and progressive enhancement, it’s just swell.

Apple's Amazing Tomorrowland Will Have Modern Browsers Understanding HTML5 and CSS3

OK, so I’ve mainly stayed silent about the whole Apple/Adobe HTML5/Flash war of passive aggressive publicity stunts. I, like most sane people, believe all technology has a place, and that fanatics of one model who take steamy blog dumps on the opposing model should largely just shut the fuck up and go back to drooling over Princess Leia Flickr groups.

But Apple’s new “HTML5” site, located at apple.com/html5, is just a bit too over eager for my liking. If you haven’t gone through it, I encourage you to do so. It’s an impressive demonstration of current technology. (Kinda.) As I clicked around, looked at the source, and tried to reason with its existence, my thought process unfolded thusly:

  1. What a self-serving publicity stunt.
  2. Well, wait, maybe there’s a good reason for this.
  3. No wait, it really is an ego-driven techno hard-on masquerading as “information”.

Indulge me as I step up onto my soapbox with my megaphone cranked to 11. Here are my issues, in no particular order other than when they occurred to me.

It’s Not Just HTML5

What drives me truly insane is that the entire mini-site is positioned as an “HTML5” showcase. Yes, they mention CSS3 and JavaScript, but you know what I’m talking about. The problem is that of the eight demos currently on the site, only three actually “showcase” HTML5 elements: <video>, <audio> and <canvas>. The rest of the effects are achieved through a range of CSS3 techniques with heavy dependency on JavaScript libraries like Scriptaculous and Prototype.

You know why? Because HTML5 is boring to the average man on the street. Most people just don’t care about data-*, new input types, attributes like hidden and all of the other goodies on the horizon. Only serious front-end engineers care about what the revised language is really going to bring. So they have to cover up the fairly dry gajillion-page HTML5 spec with a teeth-melting layer of proprietary CSS3 icing just to hold our attention.

Like the highest level politician, they are isolating a few key facts, inflating them with conveniently adjacent but functionally unrelated facts, and then broadcasting a scrubbed package of marketing wrapped up with a disarming tagline. At best, it’s discriminatory; at worst, deceptive.

Its maddening enough to invoke the <blink> tag.

So what, you ask. Who fucking cares, you say. Apple is Apple and their turds are so polished you could eat off them. But that’s the problem. Joe the CTO doesn’t care about HTML5 globals or even what a bitch properly encoding for and serving up the <video> is; they only care that they can now watch The Best of Quagmire YouTube clips on their iPad without getting an annoying DOWNLOAD FLASH button.

People are going to look at these gee-whiz demos, pee their pants, and immediately place an order for a scaling, rotating, flipping, dropshadowed, video-laden HTML5 website. It will supplant the current reigning incrimination of ignorance, “I want a Web 2.0 site.”

Already, I have had people ask me if they should transition from Flash to HTML5. Argh.

Webkit Only. Seriously?

Of course, most conveniently, you can’t view any of these demos on other browsers, not even Chrome, which is built on Webkit and (in some cases) has better standards support than Safari. The only hint that this type of technology is possible outside Apple’s magical Tomorrowland Browser is a patronizing dismissal on the opening page:

But soon other modern browsers will take advantage of these same web standards — and the amazing things they enable web designers to do.

Huh. It was news to me that Firefox did not support <video>, <audio>, <canvas>, text-shadow, opacity, transforms, box-shadow, @font-face, linear-gradients, border-radius, the contenteditable attribute and the JS libraries used to stitch things together. This, by definition, is FUD.

If one were to listen to only Apple (and there are certainly none of those people), one would think that Safari was the alpha and omega of standards support. Of course there’s nothing in there about Webkit’s shortcomings in HTML5 and CSS3 support. Or how almost everything CSS-related that they’re showing requires proprietary vendor prefixes. Proprietary. Safari relies on markup that is less portable than Flash. I’ve said it before and I’ll say it again: vendor prefixes are, by definition, the opposite of web standards.

There’s also no mention of how through smart front-end development you can engineer for all browsers with progressive enhancement.

It’s a typical, low-fidelity corporate pitch: either/or. Us or them.

It Really Is Not “HTML5 vs Flash”

Apple, in its typical passive aggressive way, is trying ever so darn hard to position the aforementioned HTML5 elements <video>, <audio> and <canvas> as replacements to comparable Flash technology. Instead of positioning HTML5 as an alternative, they should have discussed what it truly is: a complement. The job requirements dictate what technology is right for the job. In some cases, it’s both. This has been said by many smart people many times over the past few months. I hate to be the one to break the news, but both HTML5 and Flash are going to live long lives together.

Apple skews the facts and limits the audience’s exposure to few key elements in order to demonstrate that Flash is not the only way of delivering interactive experiences. But HTML5 was designed, at its core, for rich application development, including mobile, not just serving up lame multimedia files. But application development, like comparable browser support and progressive enhancement, is not mentioned. It’s just Tron and rotating text. Whee!

This is not an “HTML5 Showcase”. It’s a “Safari Showcase”. Will it create more interest and exposure to HTML5? Of course, it’s Apple we’re talking about. But this is not necessarily a good thing, because the spec is not complete, no browser even comes close to implementing it in full, and the biggest of them all, IE, is years away from all but the most basic support. HTML5 and CSS3 are the web’s common languages tomorrow, not today, no matter how hard Apple sexes them up.

Further Reading

, , , , ,

commentary + criticism

JanDW

wrote the following on Monday June 7, 2010

Hi Kevin – I share your aversion for the safari only obnoxious bullshit Apple is serving people. But I don’t quite understand your rant against html5 and CSS3.

People are going to look at these gee-whiz demos, pee their pants, and immediately place an order for a scaling, rotating, flipping, dropshadowed, video-laden HTML5 website.

I think the capabilities html5 + css3 + JS are still behind those flash in this regard, so I don’t really fear for it getting worse.

Vendor prefixes are, by definition, the opposite of web standards.

I don’t think this entirely correct. As Andy Clarke said:

Vendor prefixes generally indicate that the proposed extended CSS is either a specification candidate or has been proposed to the W3C and is being discussed and implemented in other browsers (to achieve a standard). IE filters are proprietary and vendor specific.

So they’re Webstandards in beta. I’d rather have the overhead @border-radius@ prefixes, than having to add the extra markup and create the images required for rounded corners. Also CSS3 offers more than just vendor prefixed drop-shadows and the like (e.g. interesting selectors).

…they only care that they can now watch The Best of Quagmire YouTube clips on their iPad without getting an annoying DOWNLOAD FLASH button.

I’m confused—one can’t download flash for the ipad…
also youtube supports html5 video already: http://www.youtube.com/html5

I’m not against Flash&mdash;I don’t visit princess Leia flickr groups, though I do read your blog&mdash;but I feel where HTML/CSS/JS can be used, it makes sense to prefer it over Flash.

HTML5 and CSS3 are the web’s common languages tomorrow, not today, no matter how hard Apple sexes them up.

Using graceful degration and fallbacks, and a sprinkling of JS. HTML5 and CSS3 and associated specs can be used today. I wouldn’t recommend html5 for every project yet, but certainly html5/css3 are useful already.

Kevin

wrote the following on Monday June 7, 2010

JanDW — Thanks for your thoughts. I will try to address them in order.

But I don’t quite understand your rant against html5 and CSS3.

I have nothing against HTML5 and CSS3 — quite the opposite in fact. If that’s how it came across, I need to rewrite the entire post. My point was that non-developers get ahold of some new buzz term — Ajax, Web 2.0, HTML5, and that’s what they ask for. I’ve had a dozen clients request websites that “have the web 2.0 look”. Those are the same uneducated people who will ask for an “HTML5 site”.

Regarding vendor prefixes, my position on them is not the popular one; a lot of smart people agree with your stance. Even more established rules like @border-radius@ are not consistently implemented, not to mention that radical differences in @linear-gradient@ and others. The browser vendors have taken the idea of a standard, but both the rule to invoke it and the actual results are proprietary.

Using graceful degration and fallbacks, and a sprinkling of JS, HTML5 and CSS3 and associated specs can be used today.

Yes, they can. With a heavy amount of degradation. That’s my point. A lot of this discussion (not you specifically, JanDW) fails to recognize that well over the half the world is not on a “modern browser” yet, and that these magical rules simply do not work on IE6-8, with or without JS. HTML5/CSS3 are the standards of tomorrow. They can be implemented today, for sure (I am doing it myself), but not without either visual sacrifices or intensive workarounds for our friend IE.

Great discussion. Thanks for contributing.

JanDW

wrote the following on Monday June 7, 2010

Thanks for the reply, Kevin.

The browser vendors have taken the idea of a standard, but both the rule to invoke it and the actual results are proprietary.

The idea is that different implementations are tried while the spec is still being drafted. Once a standard then emerges, aided by the experience gained from the specific prefixes, it becomes an actual spec. Browser vendors will (should) then drop the prefix and adhere to the standard. I can see the necessity for this step, and also in this respect the intent differs fundamentally from proprietary CSS.

Kevin

wrote the following on Sunday June 13, 2010

I see your point, but I find it odd that some browser vendors are not consistent in their use of prefixes. So Opera and IE9 support border-radius out of the box; when will Gecko and Webkit follow?

What annoys me most is that I see hundreds of examples on the web defining -moz-border-radius and -webkit-border-radius but NOT border-radius — ensuring their sites neither support as many browsers as they could right now, nor are they future proof.

Kevin

wrote the following on Friday June 18, 2010

Update: Safari five now supports multiple CSS3 rules (including border-radius) without vendor prefixes. Positive movement!

JanDW

wrote the following on Tuesday June 22, 2010

What annoys me most is that I see hundreds of examples on the web defining -moz-border-radius and -webkit-border-radius but NOT border-radius — ensuring their sites neither support as many browsers as they could right now, nor are they future proof.

Well,I suppose when the spec is not set yet, you can’t be sure what the final implementation is going to be. CSS Gradients had been implemented in different ways in Firefox and Safari. So what syntax should you use for the standard if it has not been prefix free in any browser. I suppose you might have a guess, and fix it later, if needed. That’s my approach anyway.

It’s not futureproof in the sense that there will be some maintenance involved: removing the prefixed properties and adding the finalized properties. But I think it beats e.g. having to create the extra presentational HTML and using images for rounded corners. Which seems less future proof to me, in the sense that it is more time consuming to implement and makes the markup harder to maintain.

You know what ‘bothers’ me more than the prefixes though? the transform and rotate CSS specs, shouldn’t that stuff be the domain of javascript? Let’s get our torches and pitchforks out and parade in front of the W3C!

JanDW

wrote the following on Tuesday June 22, 2010

Funny, from this week’s a list apart: Stop forking with CSS3

I thought you might be interested but I’ll stop stalking you now.

Kevin

wrote the following on Tuesday June 22, 2010

Jan —

Thanks for the link. Aaron Gustafson’s solution is very nice, but it is simply not efficient enough for me in the real world. To call a 17.1 kb library (minimized) plus an additional “extension” is a lot of extra page-weight plus two unnecessary HTTP calls. Adding the vendor prefixes in a CSS file is horribly annoying, but it’s only a few bytes. And I am not the only one observing this; the same thought is clearly evident in the comments for the article.