Time for some CSS debate

That’s the best pun I could think of, pretty lame to be hon­est. My first foray into shared exper­i­men­tal CSS (pro­pri­etary WebKit prop­er­ties used to cre­ate a clock ani­ma­tion) has fired up an inter­est­ing debate; where should the realm of cas­caded style sheets end?

This clock exper­i­ment does not advo­cate such use of style sheets, it is instead used to demon­strate the capa­bil­i­ties and pos­si­bil­i­ties of WebKit’s trans­form and tran­si­tion prop­er­ties. It has inad­ver­tently high­lighted the con­tro­ver­sial and unex­pected nature by which web devel­op­ers may use them. Should this cross-pollination of behav­iour def­i­n­i­tion become stan­dard? Is it risky? What might the side effects be?

Com­ments on the Ajax­ian post began the dis­cus­sion, Malic opened the debate (this com­ment is par­tic­u­larly in ref­er­ence to ‘tran­si­tion’ rather than the more widely accepted ‘transform’):

While this [is] inter­est­ing and maybe a lit­tle bit cool, I think it is inap­pro­pri­ate for Webkit to take CSS (even if only for itself) in this direc­tion. CSS was cre­ated to define style. This seems more like a behav­ior to me and that belongs to the Javascript prob­lem space. Going down the the road that Webkit is going, the ques­tion is — where do you stop? Just how much do you extend CSS to be? I think you run the risk of cre­at­ing solu­tions for prob­lems that have already been solved.

This yielded some oppo­si­tion but the major­ity sup­ported the notion, Travis Almand cham­pi­ons the new trans­form prop­erty but strongly ques­tions its counter-part:

CSS should be a style guide, not a pro­gram­ming language.

Before high­light­ing that the road to behav­iour in CSS has already begun with the much used :hover, accom­pa­nied by :active, and :focus — user action pseudo-classes, agents some­times change the ren­der­ing in response to user actions; response being the keyword.

Will Peavy com­ments that these behav­iours wreak reek of IE’s aban­doned CSS expres­sions, and edthered asks:

What hap­pens when your CSS library and your javascript library start try­ing to do the same thing to the same ele­ment, or dif­fer­ent things to the same element?

John Dowdell of Adobe has also weighed in with an hon­est rant that I heartily rec­om­mend read­ing, even if I’m slightly jeal­ous that I can­not artic­u­late my prose as well.

The clock exam­ple shows that peo­ple will use tech­nolo­gies in unex­pected ways. The cre­ators of Usenet did not intend mass adver­tis­ing. […] Stuff­ing the genie back inside the bot­tle is harder than look­ing care­fully at the bot­tle before open­ing it.
[…]
We may not be able to per­sua­sively artic­u­late why this will even­tu­ally be con­sid­ered a bad archi­tec­tural deci­sion. It’s like when ven­dors of email clients started talk­ing about how won­der­ful it would be to add hid­den graph­ics and script­ing to the emails strangers send to you. Vague warn­ings of an unsound future are at a dis­ad­van­tage to self-interested “But I wanna do it!!” evangelists.

It’s hard to per­sua­sively doc­u­ment future risks. But encum­ber­ing HTML and CSS like this is not the way to bless your own mul­ti­me­dia engine.