Is anyone else a bit slightly miffed at having to add all the different prefix variations for advanced CSS3 declarations yo?
Surely all these cool new browsers that are all for progress and sharing and open standards and the like could get together and say (something like):
"Hey FireFox. It's Safari here. How was your Christmas? You get that sheep you wanted? Anyway. Just to let you know, we've decided that we're going to start all our advanced CSS3 test declarations with -beta- and we thought it would be a good idea for all of us to do the same. You know, to keep developers' CSS manageable and save a few kilobytes hither and thither. Oh, and can you pass on the info to Opera and the others too? Thanks. Bye!"
It would mean this ...
#somethingcool {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
-o-border-radius: 10px;
-khtml-border-radius: 10px;
-ms-border-radius: 10px;
-partridge-in-a-pear-tree-border-radius: 10px;
border-radius: 10px;
}... could, in theory, become this ...
#somethingcool {
-beta-border-radius: 10px;
border-radius: 10px;
}Or, if that's just not possible
Perhaps a clever PHP egg could write some kind of parser to add the prefixes on the fly or something or nothing? Not ideal, but better than nowt ...
Anyway, here is a list of all the current CSS prefixes what I know:
-ms-Microsoftmso-Microsoft Office-moz-Mozilla Foundation (Gecko-based browsers)-o-Opera Software-atsc-Advanced Television Standards Committee-wap-The WAP Forum-webkit-Safari (and other WebKit-based browsers)-khtml-Konqueror browser
In terms of those ideas above: put them in your pipe, smoke them, have a thinky, and then let me know what your words of response be ...
COMMENTS
It'd be nice to not have that huge list, but what you suggest won't work. The reason the prefixes are there is so vendors can implement experimental CSS that hasn't been put in an official specification yet.
Take gradients for example: not in the final spec, but they're useful so (I think) WebKit and Mozilla have both implemented them. But as there isn't a final spec, and there's more than one way to skin that cat, their syntax is different.
You can't reduce them to a -beta- because the vendors would need to agree the syntax and effect to ensure the rule worked. Which won't happen because if they did agree that then there would be no need for the prefix as it'd be part of the spec already.
In a lot of cases it looks like -moz and -webkit are doing the same thing: but that doesn't mean they actually are.
As a side note, in your example you want the -prefix rules before the standard one, not after. Otherwise when the rule is finalised in FF4, or whatever, it'll apply the Web Standards version of the effect and then over-ride it with the old-school vendor specific version, as it continues to support them (I think) for backward compatibility.
So, vendor specific CSS should come first so that it gets over-ridden in browsers that support the finalised W3C implementation.
@Matt Wilcox: Aha, yes. Good point on the order of the declarations. Although that does rather 'break' my final declaration joke :P Anyway, tis fixed :)
Now here is where I don't understand. Surely any rule in any browser can be interpreted differently? Let's face it, IE has been doing it for years!
So when you're in FF, the browser reads the declaration and displays it accordingly. Then when you're in Safari, the browser reads it and displays it based on their own syntax. And so on with other browsers.
-beta- (or anything you like) would be the indication that this declaration is part of an unfinished specification.
I guess the question is: would using one declaration prefix for 'in progress' CSS mean that the syntax would need to be the same in all browsers?
I'd always assumed that the characteristics of a declaration were agreed based on specification, but the syntax to achieve this is different based on each browser engine. No?
Another point as to why I'd like a single prefix is this:
As developers, we are all quick to complain at extra mark-up - adding an empty div tag for clearing content, or adding classes to accommodate browsers that don't support advanced selectors.
Yet we have no qualms adding five times more code in our CSS to use these new enhancements.
Now, it's not going to stop me using them - progress is important - but it would be double standards if I refused to add extra mark-up and classes to a html page, when I'm happily filling my enhanced CSS style-sheet with five times more code than will be required once the specification has been agreed and put in place.
"Surely any rule in any browser can be interpreted differently?"
Not really - the point of the W3C spec is so that the rules are interpreted exactly the same. When they are interpreted differently we call that broken, and is why we hate IE.
"Would using one declaration prefix for 'in progress' CSS mean that the syntax would need to be the same in all browsers?"
Yes. Because otherwise it wouldn't work in a browser expecting a different syntax. If we take the text-shadow property as an example - it expects a syntax of: x-offset y-offset blur-radius color. But imagine it to be a -beta property and the Mozilla implementation expects y-offset and then x-offset. The result would be different in safari than in FireFox. That's why these experimental effects have vendor specific prefixes - because there isn't an agreed syntax yet, and trying to parse a generic -beta- rule wouldn't work cross-browser.
"It would be double standards if I refused to add extra mark-up and classes to a html page, when I'm happily filling my enhanced CSS style-sheet with five times more code than will be required once the specification has been agreed and put in place"
The difference is in maintainability. The argument against HTML clutter is that it should be semantically concise and to make it otherwise inhibits future re-styling and re-usability. It's less about bloat, although that tends to be more immediate a concern.
With CSS there isn't any semantic impact, just bloat. When you re-style a page you throw away all the CSS anyway. And, as you point out, you can avoid the snazzy effects if you don't want the bloat.
It's tough to criticize the code bloat considering it's our choice to use these, essentially, unfinished effects. If we were to complain about it we are effectively saying: "Why isn't this a final spec already? It should just work!".
We're playing with shiny newness that isn't finalised, code bloat is the price of playing with unreleased fanciness. It will be 5 times as big as the "final spec", but that's because there isn't a final spec yet and you can't short-cut to one without everyone agreeing on a standard for the short-cut. Which would be as slow as agreeing to a final spec.
@Matt Wilcox: Well, if browser specific prefixes are the only way, I guess that is that.
I'm still confused though. I mentioned that "any rule could be interpreted and rendered differently depending on the browser you are in". You answered "not really", but the rest of your answer read as "yes". If that's the case, then surely at testing stage a single prefix could be used across all browsers for them to do their testing before the spec is good to go?
Also, when I say "syntax", I mean the actual syntax the browser engine uses to turn our CSS into something that happens on screen. A code we do not see ourselves. Is that not different depending on the browser engine?
I agree with you on your point of choice. But at the same time you will find a great number of developers now using the new stuff - and on live and even commercial work. So why not look at this "real" situation and try and improve it?
If it is definite impossibility for a single prefix to work, then that is that. But if not, I personally believe a single prefix will make the transitional period between "testing" and "final" more efficient and manageable from the developers perspective.
Guys - I think it's jolly decent of the browser vendors to mess with their experimental stuff and the prefix is way better than the conditional comments that IE gave us - wouldn't it be nice to say -ie6-margin:4003px;
Personally I'm not bothered about adding extra lines for the experimental stuff, however I tend to just steer clear anyway because of the inevitable questions from clients when they fail to understand why they can't see the border shadow in IE7.
What would be nice though is if the validators would ignore anything with a minus prefix instead of saying:
"Property -moz-border-radius doesn't exist" etc.
Very annoying.
@Jonathan Patchett: Good point on validation. There's not much noise about validation nowadays, although it would be good if validation services offered a 'warning' rather than an 'error' for any advanced, pre-spec stuff.
Update: Alex Cabrera pointed me at a helpful CSS app to aid with repetitive tasks: http://wiki.github.com/chriseppstein/compass (via http://twitter.com/_alexcabrera/status/7234551646)
Could be useful?