This is not a tightly-honed, logical, and factually persuasive essay. I cannot predict the future well enough to induce others to change from a dangerous course. Consider this as just an honest rant. I'm quite apprehensive of the future of HTML, if enough of us do not rant longly and loudly enough. Just an unedited draft of a rant; happy Friday to ya. ;-)
The tipping point for the rant? "An analogue clock using only CSS". Paul Hayes made an (admittedly studly) example where JavaScript queries the local system's time, and Cascading Style Sheets move the hour, minute and second hands around.
Stylesheets. For animation.
Not SVG. Not an internal browser-specific drawing language. Not bitmap rotations through JavaScript.
Stylesheets.
Pervy.
Styling guides themselves have been around since SGML days. It's handy to separate presentation and content.
The "Cascading" in CSS refers to how styling choices of the designer, the reader, and the browser vendor are reconciled together. It's a tricky task, and Wikipedia has an intro to the innovations in this area in the 1990s.
What's "a style"? The original intent was font, sizing, color, and other reading attributes. This makes sense. Later it was used for layout and positioning, instead of table-based layout. That's questionable scope-creep, but is a done deal.
Now Apple is promoting styles as animation engines, transition engines, even 3D engines.
That's kinky. Otaku, chikan. Ham sup. A Kraft-Ebbing candidate, just a wee bit too twisted.
Questions on CSS already dominate the web-design mailing lists, and have done so for many years. It isn't clear how to use and practically deploy this cascade of styling instructions between creator, consumer, and browser vendor. Adding 3D and other animation into it may serve the needs of browser vendors, but does not promise to help content creators or their audiences, and runs difficult-to-predict scope creep risks.
If you want to make an animating clock in a browser, then go for it. But please don't drag poor CSS in for that task! They're style sheets people... not the kitchen sink!
Think of how such a proposal could possibly evolve. Some browsers will do animation through CSS. Some won't. We already see it with the over-ambition of Ajax: tricksy sites will request visitors to change their browser brand, or will just outright fail on the smaller mobile browsers.
If animation becomes a mandated feature of CSS, competing proprietary browsers will run the risk of being labeled as non-compliant. It raises the barriers to new browser entrants. It serves to lock-in browsers which have already developed all this extra effluvia.
Sure you can code it. But how will people see it? (And by people I don't mean "just you and your enlightened friends"... I mean universal access.) Take a tip from Hari Seldon, and think of how the technology would grow.
(Caveat: I've "known" Dave Hyatt, Dean Jackson, and Chris Marrin for years online, and I trust them as people. What I'm objecting to is the corporate drive to use a standards body to "bless" Apple's internal needs for a media-savvy runtime engine via pollution of CSS's core mission.)
(Related: Sam Ruby on HTML5 Evolution; Doug Crockford on HTML5 reset.)
Here are some of the common objections I expect to the above:
"Oh, we don't want a full 3D engine like VRML, we just want little 3D effects."
The clock example shows that people will use technologies in unexpected ways. The creators of Usenet did not intend mass advertising. The creators of email did not intend to create spam. The inventors of IFRAME and mashups did not anticipate third-party exploits. Stuffing the genie back inside the bottle is harder than looking carefully at the bottle before opening it.
"We want patent-unencumbered codecs, so toolmakers can make video tools without licensing modern codecs."
I'm with you on the goal. But putting VIDEO into the Hypertext spec is not the way to do it. You cannot require new browser vendors to follow your lead. Make an Ogg Theora plugin, so that anyone can use it, with minimal impact on the overall spec itself. Don't enact dependencies on a particular browser brand.
"But we don't want a plugin -- we want Open Video to be a First Class Citizen on The Open Web!"
So improve your plugin support! WMODE layering is still flakey across the various browsers. JavaScript/plugin intercommunication is still messier and more variable than it should be by this point. Make plugins a first-class citizen in the browser brands you control, and your video will have a wider, more inclusive audience.
"You're just saying that 'cause Flash pays your salary."
Adobe actually benefits from increased browser fragmentation, because we sell the tools that reconcile the various browser brands. And the more over-ambitious HTML becomes, the better Flash will do in comparison. But I'd rather not have that income if it comes at increased cost to people actually trying to use HTML.
Apple makes more money when it locks people into Uncle Steve's Walled Garden. Google makes more money when it knows you better than you know yourself and can sell your attention to advertisers. Web pundits earn more self-esteem when they're seen as being ahead of new trends. Web journalists earn more when they increase the power of advertising networks. Web devs earn peer respect when they code something new.
All of us have self-interest. None of us are pure. Question the arguments, don't shoot the messenger.
Fortunately, there's hope. Check out the apprehension in some of the comments at the Ajaxian write-up:
"While this interesting and maybe a little bit cool, I think it is inappropriate for Webkit to take CSS (even if only for itself) in this direction. CSS was created to define style. This seems more like a behavior to me and that belongs to the Javascript problem space."
"CSS should be a style guide, not a programming language."
"To me, it seems like Webkit is trying create CSS behaviors similar to what MS did with IE’s CSS Expressions close to a decade ago (which they have since abandoned in the most recent release of IE). I’m really hoping the W3C doesn’t add these behaviors to the CSS spec - behavior is much better suited to JS."
"I thought the whole reason for CSS in the first place was separation of purpose, removing styling from content. Now we’re adding behavior into style?"
"Why is it bad when MS goes off in wild proprietary directions with CSS, but if Safari/Apple does it it’s newsworthy?"
"I for one want CSS to do CSS, Javascript to do Javascript, HTML to do HTML and ASP/PHP to do ASP/PHP. Once we start getting into overlap of these technologies it can only cause feature bloat, confusion and problems. I want each tech to be lean and mean to do be the best at what it does and leave other tasks outside their areas for the tech designed to handle those tasks."
We may not be able to persuasively articulate why this will eventually be considered a bad architectural decision. It's like when vendors of email clients started talking about how wonderful it would be to add hidden graphics and scripting to the emails strangers send to you. Vague warnings of an unsound future are at a disadvantage to self-interested "But I wanna do it!!" evangelists.
It's hard to persuasively document future risks. But encumbering HTML and CSS like this is not the way to bless your own multimedia engine.
This is not a sound path. Think it through. Trust your gut.
A clock... in stylesheets!? There is something deeply wrong with this picture.