CSS vendor prefixes considered harmful | Hacker News Reader

CSS vendor prefixes considered harmful

quirksmode.org

40 pointsrobin_reala32 comments

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.

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?

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.

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

> 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/framewor...

Still, 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?

actually you could end up having 5:

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

I would say no, because when 2-3 browsers implement the functionality and there is common agreement on the syntax, then the vendor prefix can be dropped.

My opinion is that the only problem is that the vendor prefix for border-radius was dropped too late.

I think that makes it even messier. Now we'll have 3 stages of prefixes: vendor specific, vendor agnostic, no prefix. And using something like a generic prefix also assumes all browser vendors are on the same page and agree that the spec has been baked long enough to call it final.

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: . You can't seriously suggest that's better?

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.

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

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.

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.

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.

Your idea is way better than mine. I like it and I seriously hope it will be heard.

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.

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.

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.

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.

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.

You don't have to clean up. If they are no longer being obeyed they will just be ignored. You would only remove them if you are redesigning, in which case you remove them as you go. Just make sure if you are currently adding in vendor prefix stuff you add a general case for everyone else now. Future and backwards compatible.

Some code I found myself writing recently:

    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);
        }
    });

Would really rather not have to do something like that again.

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

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.

http://compass-style.org/ http://sass-lang.com/

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

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

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.

http://meyerweb.com/eric/comment/chech.html

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

Reply on news.ycombinator.com