11–20 of 33 posts
If they were dropped for less stable css properties, web developers would start using css hacks again.
Because newer css properties don't have consistent behavior across browsers (border-radius don't work properly with border-style in firefox), and experimental properties can even have different syntax (for example css gradients in safari and firefox).
I guess PPK gets an auto-post on anything he writes. No prefix leaves us in a situation where we have to assume each vendor implemented the draft spec properly. In the case that one of them doesn't, we're left either omitting it completely or writing conditional stylesheets for each browser. An "experimental prefix", e.g. -x-border-radius, doesn't work either because we're left in the same situation as the above case…
But what about having -x-border-radius (for those who don't care about the differences) and -webkit-border-radius (for those who do) as halo suggested? I don't see the drawbacks.
I guess PPK gets an auto-post on anything he writes. No prefix leaves us in a situation where we have to assume each vendor implemented the draft spec properly. In the case that one of them doesn't, we're left either omitting it completely or writing conditional stylesheets for each browser. An "experimental prefix", e.g. -x-border-radius, doesn't work either because we're left in the same situation as the above case…
But what about having -x-border-radius (for those who don't care about the differences) and -webkit-border-radius (for those who do) as halo suggested? I don't see the drawbacks.
Who cares about having 4 lines in the stylesheet instead of one for rounded borders? I'll happily pay that "price" as it gives me a trivial way to tweak for the individual browser peculiarities or disable it for certain browsers altogether (e.g. when a js replacement is needed because the impl is not up to snuff).
In my book vendor-prefixes are one of the few sane ideas in the CSS space. We have seen the alternative after all: -->. You can't seriously suggest that's better?
I couldn't agree more. I can't imagine how many hours of clean-up it will take for all the webmasters to clean vendor prefixed properties out of their CSS files once browsers drop them.
var fader = Faders.Default,
test = document.createElement('div');
'o moz webkit'.split(' ').forEach(function(prefix) {
test.style.cssText = '-' + prefix + '-transition-property: opacity;';
prefix = prefix === 'moz' ? 'Moz' : prefix;
if (typeof test.style[prefix + 'TransitionProperty'] !== 'undefined') {
fader = Faders.Transition;
fader.use(prefix);
}
});
Earlier quoted context omitted.
But what about having -x-border-radius (for those who don't care about the differences) and -webkit-border-radius (for those who do) as halo suggested? I don't see the drawbacks.
I don't see the advantages. Setting up that much formal convention just to prevent having -moz-border-radius and -webkit-border-radius both in the stylesheet next to each other? What do you win beyond the savings about 20 characters?
-o-superstyle
-webkit-superstyle
-moz-superstyle
-ms-superstyle
superstyle /* for new versions released after standard becomes stable */
And only if no more new browsers appear.
Border-radius has no unified syntax. Neither has gradients. Two examples that prove the thesis in this article (that all vendor prefixes are bad) to be incorrect. Having just one property to target multiple browsers that do not support the same syntax would be pretty harmful. So yes, properties that have a unified syntax can do without vendor prefixes. Nothing new, see the w3c specs. Stupid browser makers copying ove…
Exactly. Here is a table that illustrates this well. I didn't know there were so many optional arguments in the standard. This page is worth viewing both in webkit and gecko based browsers, so that you can see the "your browser" column. (Firefox does much better than Safari).
http://muddledramblings.com/table-of-css3-border-radius-comp...
Perhaps there's a middle-ground solution - a universal prefix that denotes experimental or non-standard features that may be liable to break or not work cross-browser. In the long-term (i.e. a major browser release), once the property is stable and has been standardised (or is a de-facto standard) then the prefix can be dropped. This experimental prefix could exist side-by-side with vendor prefixes to allow for worka…
Its not just IE that's quirky - Firefox, Chrome, and Safari all have CSS bugs that have to be accounted for. Its hard enough to target them individually now, but under your proposal it would be nearly impossible.
But of course, this is not what the author is discussing at all. He doesn't have a problem with vendor specific prefixes in general, but rather feels they should be deprecated more aggressively once widespread adoption occurs.
Earlier quoted context omitted.
But what about having -x-border-radius (for those who don't care about the differences) and -webkit-border-radius (for those who do) as halo suggested? I don't see the drawbacks.
I don't see the advantages. Setting up that much formal convention just to prevent having -moz-border-radius and -webkit-border-radius both in the stylesheet next to each other? What do you win beyond the savings about 20 characters?
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.
.my-container
+border-radius(3px)