3 ms·
Personally, I can think of a few advantages. Duplicating 2 or 3 lines may seem like a minor problem, but having to change those 2 or 3 lines every time you mak
by halo 17y ago
Personally, I can think of a few advantages.
Duplicating 2 or 3 lines may seem like a minor problem, but having to change those 2 or 3 lines every time you make a change quickly becomes a maintainence burden, especially when they're littered throughout your CSS. The extra burden such prefixes brings is greater than the amount of extra characters they add.
Not having to alter your code every time a new browser comes along that is identical to existing implementation is useful, especially since most of the time browsers copy each other's features or implement standards unchanged. This is especially useful since most sites using bleeding-edge features are either tech demos or test-cases.
A non-universal prefix also favours large players and has the potential to squeeze out less popular browsers even if they support the same feature. Even if Opera supports the same standards as Firefox, you can can bet that more people will use the -moz prefix than -o.
The "risk" is that your code will break in unpredictable ways, but the upside is that risk is known (since it's part of the "contract" from the prefix), manageable, greppable, and can be worked-around.
- jacobolus 17y ago> having to change those 2 or 3 lines every time you make a change quickly becomes a maintainence burden, especially when they're littered throughout your CSS. You make a good argument for generating CSS via some kind of more programmable system. > Not having to alter your code every time a new browser comes along that is identical to existing implementation is useful And what about those times when the new browser isn’t identical? I'd hazard that that’s more usual with this kind of experimental new features.
- grayrest 17y ago> Duplicating 2 or 3 lines may seem like a minor problem, but having to change those 2 or 3 lines every time you make a change quickly becomes a maintainence burden, especially when they're littered throughout your CSS. The extra burden such prefixes brings is greater than the amount of extra characters they add. http://github.com/chriseppstein/compass/tree/master/frameworks/compass/stylesheets/compass/css3/ http://github.com/chriseppstein/compass/tree/master/framewor...
- pohl 17y agoStill, I'm not swayed. I would rather have the current mechanism, which allows me to deal with the syntactic and semantic differences on a browser by browser basis. The current situation is an escape valve for the inevitable flux & lag between the standards process and implementation compliance. If you invent a universal prefix you no longer have as much of an escape valve...you just have a namespace where you accept random non-compliance. And if you're ok with one such namespace, then why not one for each rendering engine, so that they're at least compartmentalized a bit?