CSS vendor prefixes considered harmful
quirksmode.org
CSS vendor prefixes considered harmful
1–10 of 33 posts
Re: CSS vendor prefixes considered harmful
#2I 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.
Re: CSS vendor prefixes considered harmful
#3Perhaps 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 workarounds for broken draft implementations.
Re: CSS vendor prefixes considered harmful
#4I 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.
I think ppk is wrong here. Completely wrong.
As mentioned in the comments of the article, this would mean the first to implement a new feature would be able to define how it works. Not a good idea. We need some form of consensus.
And also mentioned: some things do change. The definitions of border-radius for Gecko and Webkit are not the same at all.
Re: CSS vendor prefixes considered harmful
#5I agree that these are annoying for developer and somewhat harmful for traffic. However the real problem lies in politics. When browser representatives suggest a new standard and everyone says "fine, we like it but we must think about it" it makes sense to implement this standard in vendor specific way. That serves as a live example for all developers, standards committee and developers of other browsers, yet nobody can blame them for implementing new standard cowboy style and trying to get it become de-facto before everyone has agreed like MS use(d?) to do. The question is "when should the vendor prefix go?" Obviously right now it's happening too slowly so maybe the whole process needs to be improved and maybe there needs to be a mid-state for new standards - one that is not "in-draft" and not complete either ("release candidate", ha!).
Re: CSS vendor prefixes considered harmful
#6Perhaps 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…
Your idea is way better than mine. I like it and I seriously hope it will be heard.
Re: CSS vendor prefixes considered harmful
#7Border-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 over -o-* to webkit browsers however, should be considered harmful. We should target those.
Re: CSS vendor prefixes considered harmful
#8Perhaps 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…
That's rather common with MIME types, HTTP and MIME headers, where experimental or vendor-specific extensions get prefixed with "X-". The same thing could work here, I agree. I think that "-x-transition" would work better than "-webkit-transition", frankly.
Re: CSS vendor prefixes considered harmful
#9I 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. As on of the commenters on quirksmode.org pointed out, the gradient implementation in Webkit is significantly different than the one proposed by Mozilla. Using a unified prefix wouldn't help anything.
I guess one could say that we shouldn't be using draft specs in production code but that also seems counterproductive as it doesn't give us the chance to field test new functionality.
Re: CSS vendor prefixes considered harmful
#10I 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.