

CSS vendor prefixes considered harmful - robin_reala
http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html

======
bentruyman
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. 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.

~~~
kaitnieks
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.

~~~
pohl
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?

~~~
halo
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
> _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.

------
moe
I don't see the problem. I _like_ vendor-prefixes.

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: <!--[if IE]> \-->. You can't seriously
suggest that's better?

------
kilian
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 over -o-* to
webkit browsers however, should be considered harmful. We should target those.

~~~
pohl
_Border-radius has no unified syntax._

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...](http://muddledramblings.com/table-of-css3-border-radius-compliance)

------
halo
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 workarounds for broken draft implementations.

~~~
qeorge
The problem is that unless two properties are actually going to work the same
way, we can't use the same prefix. We have to be able to target individual,
misbehaving browsers.

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.

------
tlb
I include this kind of rewrite in my webserver, so my CSS files stay clean.
For instance,

    
    
      data = data.replace(/^\s*border-radius:\s*(\w+);$/mg, 'border-radius: $1; -moz-border-radius: $1; -webkit-border-radius: $1;');
    

I just have to change it in the one place when some new CSS tweak comes along.

~~~
cheald
I solve it with Sass, which lets me define "functions" (more like macros,
really). <http://pastie.org/881370> is what I use for corners - just tweaking
the macro definition as needed provides what I need.

In regards to the article, other people have touched on why we can't drop
vendor prefixes just yet. Not all vendors implement a feature consistently
yet. In the case of something like border-radius, the shorthand forms mean
completely different things in different browsers, and the longhand forms
don't have consistent naming.

Vendor prefixes serve a very valid purpose - the ability to say "we've
implemented an interpretation of the CSS3 draft standard, use at your own
peril" is wonderful, because you don't need CSS hacks and horrible rewrites
and all sorts of other voodoo to work around problems.

------
psadauskas
His main gripe of making CSS more verbose than it needs to be can my solved
easily with SASS:

    
    
        .my-container
          +border-radius(3px)
    

And the implementation: <http://gist.github.com/340185> Its easy to add more
vendor implementations to this macro, each with their own quirks handled.

------
CWIZO
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.

~~~
roam
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.

------
valums
I think, that vendor prefixes prevents us from getting into incompatibility
nightmare.

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).

------
mseebach
We need something like jQuery for CSS. One, sane, extendible API/DSL that
works the same on all browsers, with all the quirks taken care of behind the
scenes.

~~~
yesbabyyes
<http://compass-style.org/> <http://sass-lang.com/>

------
Kilimanjaro
What if we had 10 browsers or more?

Nightmare!

I am against vendor prefixes, but if they are needed we should do the opposite
we are doing today, let me explain:

use border-radius everywhere

browsers that don't support it just ignore it (like html5 tags)

browsers that do, just show them

browsers with special implementation of it, THEN use vendor prefixes

So we only write one border-radius and if we care about that rogue vendor,
then we just add an extra -?-border-radius

Personally I wouldn't care about rogue vendors.

Believe me, I am sick of writing five times the same style, testing, changing
it five times again, and some time in the future, my code will be polluting a
already established standard, so I am going to have to come back to change it
again.

I got sick of it, so what I do right now is to have a second stylesheet only
for vendor specific styles, so all I will need to do is just remove that
stylesheet when the dust settles.

Still retarded...

------
kaitnieks
I 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!).

------
bestes
I love PPK's new writing style.

Most of the comments so far seem to be arguing a few specific details; I think
that misses the point. PPK is arguing (in an over-the-top way, which makes it
more fun to read) that convergence sooner rather than later is a good thing.
For some of the more clearly defined properties (like border-radius), the time
is NOW.

His characterization of the goals of browser developers seems to be right on
as well. It will probably change again over time, as most competitions do, but
today the top competitive advantages seem to be performance, stability and
standards compliance. So, the mindset from the last generation of competition
(differentiation) is no longer appropriate.

------
chrisbolt
<http://meyerweb.com/eric/comment/chech.html>

------
InclinedPlane
News flash: using experimental, unstandardized features can be risky, and
requires more work on the developer's part.

