I'm writing a CSS book
JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH
QuirksMode
PPK contact

CSS vendor prefixes considered harmful

I recently came across a post about border-radius by the IE team, that said IE9 supports border-radius (cool!) without vendor prefix (even cooler!)

The post continues:

While a number of web pages already make use of this feature, some [...] do not render properly in IE9 or Opera 10.50 because they lack an unprefixed declaration of the border-radius property.

As the specification nears Recommendation and browser vendors are working on their final implementations and testcases for submission to the W3C, we recommend that new content always include a border-radius declaration without vendor prefix.

I’d like to go one step further.

It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.

Vendor prefixes force web developers to make their style sheets much more verbose than is necessary, while also running the risk of accidentally forgetting one set of vendor-prefixed declarations.

Besides, why do we need to use several declarations for obtaining one single effect? Weren’t web standards supposed to prevent that sort of thing?

Guys, let’s stop the vendor prefix nonsense. Enough’s enough.

Update: Although the problem is real, my solution is not the best one possible. See the redux for more discussion.

The point

Originally, the point of vendor prefixes was to allow browser makers to start supporting experimental CSS declarations.

Let’s say a W3C working group is discussing a grid declaration (which, incidentally, wouldn’t be such a bad idea). Let’s furthermore say that some people create a draft specification, but others disagree with some of the details. As we know, this process may take ages.

Let’s furthermore say that Microsoft as an experiment decides to implement the proposed grid. At this point in time, Microsoft cannot be certain that the specification will not change. Therefore, instead of adding grid to its CSS, it adds -ms-grid.

The vendor prefix kind of says “this is the Microsoft interpretation of an ongoing proposal.” Thus, if the final definition of grid is different, Microsoft can add a new CSS property grid without breaking pages that depend on -ms-grid

Now in itself this is a reasonable line of thought. Point is, it’s outlived its usefulness. It’s just not necessary any more, neither from a practical nor from a more philosophical point of view.

Practical problems

Let’s take a look at some practical cases.

box-sizing

One place where vendor prefixes have always annoyed me terribly is the box-sizing property that allows you to switch from one box model to another. Currently IE8 and Opera support box-sizing without prefix, but Firefox supports only -moz-box-sizing and Safari, Chrome, and all mobile WebKits only -webkit-box-sizing.

In other words, this is the code to switch the box model of one div.

div.borderbox {
	box-sizing: border-box;		/* one */
	-moz-box-sizing: border-box;	/* two */
	-webkit-box-sizing: border-box;	/* three */
}

The fact that I have to use three declarations for obtaining one effect is completely preposterous. We might as well live in the Browser Wars era. Standards, anyone?

The point here is that box-sizing will not change any more. Its purpose is to switch box models, and its two values border-box and content-box are supported everywhere.

This declaration makes sense as it is, and it is supported by all browsers as it is. So it should have the same name in every browser.

Why wait for W3C to put its stamp of approval on it before removing the prefixes? We all know that’s going to take another five to ten years.

Mozilla, WebKit, you’re just being thoughtlessly conservative here. Get rid of your vendor prefixes.

Transitions

Consider the transitions Safari added. They’re all prefixed with -webkit-. Here, too, the point is that the Safari team has effectively specified all these declarations. They’re not going to change any more.

Google and Opera are implementing transitions, too. I studied the Apple and Opera documentations a bit, and they look quite alike. In fact, right now I dare state that Opera is working to copy Apple’s transitions system.

But Apple uses -webkit-transition, while Opera is using -o-transition.

Guys ...

div.coolEffect {
  -webkit-transition-property: opacity;	/* one */
  -webkit-transition-duration: 2s;
  -o-transition-property: opacity;		/* two */
  -o-transition-duration: 2s;
  -moz-transition-property: opacity;  		/* three */
  -moz-transition-duration: 2s;
  -ms-transition-property: opacity;		/* four */
  -ms-transition-duration: 2s;
}

I don’t want to use four browser-specific declarations to obtain one effect! This sort of vendor-specific nonsense is exactly what web standards were supposed to do away with. No more bloody fragmentation!

What if a web developer accidentally forgets one vendor prefix? Then the effect won’t work while it could — something we’ve learned to recognise as a grave sin. Still, it’s bound to happen in a standardless world.

Enough’s enough. Vendor prefixes have to go.

A peek into the future

The most idiotic example comes from the mobile world. Opera has implemented a touchscreen media query in the Vodafone widget manager, and called it -o-touchscreen.

When Samsung started to work on its WebKit-based widget manager, it was notified of the existence of this media query and promptly copied it. To the letter.

Thus, we now have a WebKit browser reacting to -o-touchscreen.

And this is just the beginning. It’s going to get much, much worse.

Eventually Opera will discover that plenty of sites use -webkit-transition, but not -o-transition. Will Opera start to support -webkit-transition, too?

From a compatibility perspective that might make sense. From any other perspective it’s totally ridiculous, though. And there’s a simple solution to this problem: transition has become a de-facto web standard. So treat it as one.

Let’s stop the vendor prefix nonsense. Now.

Philosophical problems

So from a practical perspective vendor prefixes are turning into a tool for fragmentation. From a philosophical perspective, moreover, they solve problems that just aren’t there any more.

As far as I can see vendor prefixes were supposed to solve two problems:

  1. The problem with unfinished standards I outlined earlier.
  2. The problem underlying that problem: an automatic assumption that, when left to their own devices, browser vendors would all start to implement their own stuff without paying attention to what the other browsers were doing.

Both problems have meanwhile been solved, as far as I can see.

We’re currently moving toward a situation in which anything that is implemented by two browsers more-or-less automatically becomes a standard. I don’t think that this change of process has been accepted by W3C yet (it might take another generation), but it’s becoming reality as we speak.

The reason this system can work is because browser vendors now want to copy each other’s implementations! Microsoft, Mozilla, Apple, Google, and Opera are all eyeing each other’s browsers and want to resemble each other in standards support, while competing in execution excellence, interface smoothness, and standards extension.

Contrary to the Browser Wars era when vendor prefixes were defined, right now browser vendors are genuinely interested in interoperability. There is no danger any of them will go off on a wild tangent and, I don’t know, redefine box-sizing: border-box to mean “anything inside the border.” That sort of thing just doesn’t make sense any more today.

The Safari team invented cool, new transition stuff. They made it CSS-based, documented it, and submitted it to W3C. That’s all good.

Then they added the -webkit- prefix. That’s bad.

Now Opera comes along, and wants to support transitions, too. Is Opera going to invent its own system? Is Opera suddenly going to give transition a completely different meaning that is totally incompatible with Safari’s?

Of course not! The Opera guys aren’t crazy. They know their bread is buttered on the compatibility side of things. The same goes for all other browser vendors.

But they do add their own vendor prefix. That’s ridiculous. And pointless.

transition and all the rest have become de-facto standards. Any browser implementing the transition system will make sure that it is compatible with Safari. So who needs vendor prefixes?

Dear browser vendors, take a little more pride in your willingness to work with your competitors towards web standards, even when you invent new functionality. You do not need vendor prefixes any more. You’ve grown beyond them.

The time has come to abolish all vendor prefixes. They’ve become fossils of a bygone era, but with the potential to harm web standards significantly.

Update: Although the problem is real, my solution is not the best one possible. See the redux for more discussion.

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?

Categories:

Comments

Comments are closed.

1 Posted by Mike Taylor on 22 March 2010 | Permalink

I disagree that the transitions module is a de facto standard--it's only a working draft right now. As you know, vendor prefixes aren't dropped until a specification reaches Candidate Recommendation--hopefully preventing the syntax rug from being pulled out from under your feet.

But I definitely agree that 4 prefixed props is too many. Something more generic like, -draft-foo or -x-foo would be less painful. Note that this has been proposed and is under discussion on www-style: http://lists.w3.org/Archives/Public/www-style/2010Mar/0026.html, and elsewhere.

2 Posted by Joe Critchley on 22 March 2010 | Permalink

I read the title of this and thought it was a bit idealistic; but after finishing reading it, I think you've made a good point.

For the simple properties, is it really that much of a job for vendors to get swap then over to the proposed standards?

This might be a bit naiive, but doesn't the real problem lie in standards taking too long to be decided on?

3 Posted by Mathias Bynens on 22 March 2010 | Permalink

So you’re saying the first browser to implement new CSS features will get to pick how exactly it’s implemented?

That actually sounds a bit dangerous. I sure hope Microsoft doesn’t invent a lot of new CSS stuff.

4 Posted by Michel on 22 March 2010 | Permalink

Extremely good points! And I have to agree. With all of them! :)

Unfortunately, as far as I can see, for now we will have to live with browser specific prefixes in CSS... Because I do not see any sign from Mozilla, Opera, Chrome or Apple, that they are planning to switch from vendor specific to standard.

I would prefer to just type:
div {border-radius: 10px;}
and move along, but instead, I have to type this rule 4 times and add the various browser prefixes: -webkit -moz and even -khtml (if I care supporting Konqueror)...

Any idea how browser makers can be influenced? :)

5 Posted by kl on 22 March 2010 | Permalink

Some properties do change. WebKit's gradient syntax is disgusting and -moz one is much more humane.

And have you seen webkit reflections monstrosity!?

I don't want those in global namespace. Yuck!

6 Posted by Kilian Valkhof on 22 March 2010 | Permalink

Border-radius has no unified syntax. Neither has gradients. Two examples that prove your thesis (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. Target those.

7 Posted by Dustin Wilson on 22 March 2010 | Permalink

I agree with you when it pertains to things like this, and historically Opera has avoided using its vendor specific extension for things such as this. Transitions are the first thing I can remember in a long while where Opera's used their -o- prefix. Mike's comment pretty much outlines the usefulness for prefixes. It'd be a disaster for a browser to have implemented a feature only to have its syntax completely change because the spec's not yet out of the draft stage. Having a specific prefix for experimental features would be preferable such as -draft- or -exp- or something of the sort.

However, there's an actual use for vendor prefixes, and that's for true application specific features. Opera uses HTML to render a lot of features used within the browser from mail to the info panel. The lot of them use vendor prefixes such as the -o-skin CSS property, allowing it to tie into the user's skin for graphic elements. Removing vendor specific prefixes would force Opera and other vendors using similar things to just create new properties which is actually more harmful than using the prefix itself.

8 Posted by Niels Leenheer on 22 March 2010 | Permalink

I would have to agree that the situation where you need to specify 3 different css rules to get one effect working in all browser is an unwanted one.

But I would argue against that simply dropping vendor prefixes is a proper solution. It isn't. It would only cause more problems.

The fact is that some features are implemented before there is a proper standard and agreement over the correct syntax to use. Until there is agreement over the syntax you must use vendor prefixes otherwise you end up with different browsers implementing the same feature using different syntaxes and vendors having to correct their syntax along the way. Which obviously causes problems for existing content that depends on a certain syntax.

Take for example border-radius. The syntax implemented by Mozilla is different from the rest and the official standard. A vendor prefix prevents us from having to use browser sniffing to send the correct rules. The same applies to gradients. Mozilla uses a different syntax from the original in Webkit.

The problem isn't vendor prefixes, but the long process that standards take. The solution is to speed up that process and move as quickly as possible to drop the prefixes as soon as there is agreement over the syntax.

9 Posted by Yaili on 22 March 2010 | Permalink

I agree.

It's a bit ridiculous the verbosity that goes on to a stylesheet that uses the most recent CSS stuff. And the constant back and forth, googling, making sure every single rendering engine is catered for, ugh.

And what makes me even more annoyed is how so many people completely "forget" to add the default properties to their CSS.

Haaa, Monday rants! :)

(On a happier note, on the latest Webkit nighly, border-radius is accepted, whee! Box-sizing still isn't though…)

10 Posted by Matt Brubeck on 22 March 2010 | Permalink

I was going to make the same point about -webkit-gradient and -moz-gradient. It seems like you've cherry-picked examples that support your case, while ignoring cases where vendor prefixes turned out to be a good idea. Are vendors supposed to predict the future to know whether a given prefix is necessary?

I agree there's a problem when prefixed names become de-facto standards. But the problem is not the implementers; it's the W3C. Vendor-prefixed names would normally be used only by bleeding-edge sites that don't care about compatibility or legacy browsers. But CSS3 has been in various stages of draft since 2005, and a whole generation of browsers has come and gone without a new standard finalized enough to rely on. There are no major CSS2-only browsers left, so content authors are using the CSS3 draft implementations in mainstream work. If the relevant CSS3 modules had reached, say, candidate stage a year earlier, this would be a much smaller problem.

11 Posted by Oliver on 22 March 2010 | Permalink

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.

12 Posted by Oliver on 22 March 2010 | Permalink

I forgot to mention that vendor prefixes could (and should) exist side-by-side with an "experimental" prefix, so that if a property works incorrectly in one browser you can work-around it by using the vendor prefixes.

I think vendor prefixes are are necessary evil, but I agree that some of the pain needs to be removed for common use-cases.

13 Posted by secoif on 22 March 2010 | Permalink

My friend @wolever mentioned CSS compilers (eg http://lesscss.org/) as a possible solution to this problem.

Most wouldn't use javascript without a framework dealing with the browser incompatibility, so why is it we use CSS without something similar to take away these types pains?

14 Posted by Azat Razetdinov on 22 March 2010 | Permalink

JFYI: if you check new CSS properties support in JavaScript, be careful:

typeof style.WebkitTransform === 'string'
typeof style.MozTransform === 'string'
typeof style.OTransform === 'object' // WTF?

15 Posted by Roland van Ipenburg on 22 March 2010 | Permalink

If a web developer wants to use stuff that hasn't reached some standardization yet he's on his own and shouldn't blame browser makers for making his job slightly harder. The problem is that a lot of web developers enjoy living in a world of beta versions and nightly builds and are very eager to jump onto any new feature that comes along, and then get themselves in the described mess that way. With that mentality standards won't help you. The point of the vendor prefix is that the same engine can be deployed in both a generic browser and in an environment where content is aimed at just that single engine, for example an interface of a device based on an embedded browser, without polluting the standard namespace. So if for example there is some browser out there doing the glass cockpit for Airbus with specific features for that using the -airbus prefix, don't be surprised if your job gets a bit harder when you adopt those features in your desktop or mobile site because you think you're cool.

16 Posted by Tab Atkins on 22 March 2010 | Permalink

Re: transitions vendor prefixes being silly

Hakon Lie, from Opera, just proposed a relatively large change a few days ago to unify Transitions and Animations. If we had done as you said, we wouldn't be able to make a change like this without coming up with a new name entirely.

Some properties are, probably, stable enough to lose their prefix without their spec being in CR. The CSSWG discussed this very thing on the mailing list recently, and we'll discuss it more at our upcoming ftf. But, as a general policy, vendor prefixes are definitely still worthwhile and good. The minor annoyance you have to put up with to use experimental properties is nothing compared to the pain of a bad idea getting prematurely baked into the web platform.

We've had far too much of that on the web already. CSS is one of the few places that's gotten it all close to right.

17 Posted by Pete B on 22 March 2010 | Permalink

Vendor prefixes are a pain, yes.

But I think, as others have already noted, that they're necessary in some cases given the different implementations (or interpretations) of the newer CSS3 properties that are already out there.

Where the vendors have consensus on how new properties should be implemented then the prefixes should be dropped. I'm pleased Opera has already taken the lead on this

18 Posted by victor on 22 March 2010 | Permalink

So what about css gradients? webkit and mozilla have different syntaxes. While they serve the same purpose, here having to repeat the declarations is a must, as they offer slightly different capabilities

19 Posted by riddle on 22 March 2010 | Permalink

Mozilla supports padding-box in their -moz-box-sizing. Isn’t that the whole reason for having vendor extensions? If you don’t support something like standard bodies told you, add a prefix. Otherwise, why bother?

Text-shadow is a good example.

20 Posted by Vladimir Carrer on 22 March 2010 | Permalink

Amen, Brother!

21 Posted by Jadet on 22 March 2010 | Permalink

I'm not sure if you follow your own logic when claiming that some problem with unfinished standards has been solved. There's nothing to solve there, unfinished standards aren't a problem, they help create new standards and speed up finishing them. Suggesting that browsers have grown beyond vendor prefixes is like telling them to start experimenting out in the wild.

The underlying problem here seems to be laziness.

22 Posted by Chris Casciano on 22 March 2010 | Permalink

css gradients, targeting specific rounded corners in webkit vs. others, the old (old, old) value behavior of moz-opacity.

There's one good solid reason for vendor extensions to exist today and remain in existence moving forward - as an indicator to the developer that the code their writing isn't stable.

Now, publishing instable code has many, many downsides particularly when we're publishing web pages that may be around and untouched for years to come, so you could just maybe find reasons to say publishing production code using vendor extensions might in some ways be harmful, but don't blame the extensions for that.

23 Posted by Ben Cherry on 22 March 2010 | Permalink

I don't think its time to do away with vendor prefixes altogether, for, as you say, they do serve a good purpose for experimental features. But we need to convince the browser vendors to be actively ending those experiments that have run their course, and moving to common ground. This means dropping vendor prefixes for the rules that have reached consensus, and reaching consensus and then dropping vendor prefixes for those that haven't. You don't need to wait for CSS3 to become a finished standard before sitting Mozilla, Google, Apple, and Microsoft down and banging out a mini-standard for those CSS3 rules that everyone implements already.

24 Posted by Frans on 22 March 2010 | Permalink

I have to disagree. -moz-border-radius is slightly different in some ways and lacking in others. Of course, now that the spec has stabilized, Gecko can be fixed so that its support for border-radius is correct and doesn't require the prefix anymore. Admittedly, there's some overlap between two different things here, i.e. vendor-specific stuff such as -o-skin and experimental implementations.

Just consider the following situation: currently the problem (according to some) is that Opera and IE9 don't read -moz-border-radius, or rather that all the webpages didn't bother to specify both -moz-border-radius and normal border-radius. Wouldn't it be far worse if Mozilla hadn't used the prefix and Opera's and IE9's correct implementation were to "break" on the existing CSS because the spec changed a little here and there as opposed to ignoring it?

25 Posted by Eric Meyer on 22 March 2010 | Permalink

If you were to push to outlaw all vendor prefixes AND replace them all with some kind of universal "this is still experimental" prefix, then I'd be in agreement. Or at least wouldn't disagree.

If you're arguing to drop all prefixes, period, then no, I can't agree. My experience with 'clip'—a property that was doomed by an early un-prefixed implementation and a subsequent change of specified behavior—can admit no other stance.

26 Posted by Tomas Caspers on 22 March 2010 | Permalink

There's been more than just a handful of situations where I was really grateful for vendor prefixes. Especially when some browsers claimed to support a certain property, but then failed to recognise essential keywords (e.g. box-shadow: inset 1px 1px 1px #ccc; in Safari versus Firefox - since Safari doesn't support inset shadows, you need some kind of mechanism to hide them from each other)

27 Posted by Simanek on 22 March 2010 | Permalink

The browsers should not change their support of CSS based on how website developers use vendor-prefixed CSS. Developers are going to use whatever is available to get the job done. They often break with 'standards' for the sake of making a real, working site. No one can stop that, but it is the reason that web developers' disregard of the specification should not dictate any browser's implementation of the specification.

As a web developer, if you want to use these experimental features you need to accept the messy methods that need to be employed in order to make them work across all popular browsers. If you don't like that then you need to simply stick with the officially recommended CSS specifications.

28 Posted by Jan Philipp Pietrzyk on 22 March 2010 | Permalink

Justbecause Microsoft steps ahead and trys to make a common border-radius property, does not make the whole system vendor-prefix less work. They ARE experimental to his moment and will be for the forseeable future. Just to recall: IE6 understands most common CSS2 propertys but behaves different. The prefix system prevents this in a good way, but the W3C does not speed any process so we need better standarts instead of better syntax over better functionality.

Remember: Most of the prefixed-propertys do not behave the same across all browsers and in all cases.

29 Posted by Pascal on 22 March 2010 | Permalink

No mention of SASS here?
It won't solve the philosophical problems, but you can't forget a certain prefix that easy.

30 Posted by ppk on 22 March 2010 | Permalink

Well, if Eric Meyer, Andy Clarke, and Jonathan Snook all think I'm wrong I must consider the possibility that they're right.

That said, I still feel that, even though my solution might be incorrect, there's a very real problem here.

I admit that that problem could also be solved by a generic "watch it"-prefix that's used by all browsers; let's call it -beta-

So...

Any chance -beta- might be implemented?

31 Posted by Thomas Scholz on 22 March 2010 | Permalink

Opera uses -apple-dashboard-region in it’s own widgets – illustrating your argument of the copy disaster.

Generally, i think, buggy implementations are better hidden behind a prefix. Otherwise we had to use and remember more hacks.

32 Posted by Jadet on 22 March 2010 | Permalink

-beta- wouldn't work since individual vendors implement unfinished standards differently.

A generic prefix will take away room for experimentation and turns the web into an experimental mess. Same thing goes for leaving out the prefix, that's why this is something that doesn't need fixing.

33 Posted by Daniel on 22 March 2010 | Permalink

Like others have said before: The first come, first serve approach doesn't seem right. Just think of CSS gradients for example. Webkit had them first, but i still like the Gecko syntax way better.

I also wouldn't want the same CSS rule behave differently in different browsers. Then i'd rather have vendor-prefixes, so i can choose.

So, yeah, stop crying and take it like a man! ;-)

34 Posted by Jan Philipp Pietrzyk on 22 March 2010 | Permalink

@Jadet & @ppk

Why not design it that way? Prefixed Propertys are not for common use, so building a unified namespace would actually help, since you can't use a property till it's mature enough. This could also speed things up, unless the first browser simply renames there property and releases this... There is no answer, I think.

35 Posted by Benjamin Grosse on 22 March 2010 | Permalink

Since browsers implement new properties differently, they could potentially implement the same feature, with for example two parameters of the same type, but swap their order. Then neither the proposed nor a temporary common syntax would work out.
That said, W3C proposed syntaxes should get adapted as soon as possible, even if that means legacy-supporting vendor-prefix syntaces too.

36 Posted by bmeck on 22 March 2010 | Permalink

While most opposition to the idea of them being in a unified namespace does have a clear point of drafts not being specified, isn't it the duty of a maintainer to keep the styling up to date? Who is to say the vendor-specific specification cannot change as well?

There is a responsibility as a designer using a non-standard/draft specification to keep that up to date as the specification changes.

It seems that many people posting do not note that extensions to CSS (values in particular) and properties that are based upon drafts often attempt and are homogeneous with the CSS specification through omission.

I feel that the need for prefixes should only apply to separate drafts beyond the standard CSS specification of the time. Otherwise all browser should be striving to achieve the same specification.

Lastly, the comments about vendor's having different interpretations entirely I feel would be better solved using something akin to !vendor, which could be appended to the end of a rule if you want non-standard interpretations (though I feel non-standard values should not enforce a need for prefix/vendor specification).

37 Posted by sethaurus on 22 March 2010 | Permalink

It would be excellent if browsers began to separately namespace their experimental CSS properties with two simultaneous prefixes: -vendor- and -draft-. This would mean that a developer wanting to use a draft property like border-radius, with currently divergent syntaxes, would specify it once per vendor. Later, when the implementations begin to converge, the developer could optionally switch to
a single declaration, using the -draft- prefix for brevity. When the property becomes standardized, the prefix could be dropped altogether.

38 Posted by Roland van Ipenburg on 22 March 2010 | Permalink

You're looking at the issue from the wrong side. The vendor prefix allows vendors to put special stuff in their engine in a way that doesn't conflict with future standards or other vendors. Stuff that could be totally proprietary and not aimed at becoming an open standard at all, but still completely shares the codebase of a standards compliant engine. The fact that there are some major open source engines that publish their vendor specific additions and then web developers instantly adopt them makes it all seem a bit pointless, but a standard like CSS has to cater for more than just the average webkit and mozilla on desktop and mobile.

39 Posted by Frans on 22 March 2010 | Permalink

@37 bmeck:
"Who is to say the vendor-specific specification cannot change as well?"

That's at least partially my point. It's saying "this is experimental and it can change at any moment for any reason." If you're using -moz-border-radius and Mozilla changes the way it works (most likely because of a change in the specification or bug fixing since the implementation may still be immature) then you really can't complain that they "broke" your CSS. Of course I'm not saying that nothing will ever change in the stable, non-prefixed properties, but ideally that would only involve bugs in edge cases. It's not only for features for which the spec hasn't stabilized yet, it's also for incomplete or buggy implementations of perfectly stable properties.

"It seems that many people posting do not note that extensions to CSS (values in particular) and properties that are based upon drafts often attempt and are homogeneous with the CSS specification through omission."

Really? It started at comment 3 with "That actually sounds a bit dangerous. I sure hope Microsoft doesn’t invent a lot of new CSS stuff." and there's a lot more along the same lines in the comments.

40 Posted by Pete Nicholls on 22 March 2010 | Permalink

All your examples use CSS extensions with identical implementations. Your idea might work well if that were the case across the board, but consider, for example, the different implementations of CSS gradients between WebKit and Gecko.

Something simple, like the syntax for making a radial gradient inside a box, deviates significantly between the two rendering engines. What syntax works for one browser, falls down in the other.

Conceivably, the two browsers will come together on a unified standard, but until then, the vendor prefix is an invaluable experimentation flag.

41 Posted by John Allsopp on 22 March 2010 | Permalink

For all their faults, as legitimately documented here by PPK, I'd actually go so far as to suggest browser prefixes saved CSS, and in some ways the web as a platform. Big call, but without them, CSS would be mired in the CSS2 days. And as a consequence, developers and designers would have given up on the web as an application platform.

When border radius was first implemented by Firefox, is was so poorly done, that given the choice of

1. have it work in both Safari and Firefox
2. have it work in neither

almost any developer/designer would choose option 2. Hence no adoption, hence no designer/developer buy in, hence no pressure on other browsers to implement, hence no change from 1999.

CSS3 has greatly benefited from it's flexibility, and modularity (a lesson BTW HTML5 could IMO learn from). And extensions have been at the heart of the flexibility. I can safely use a new CSS property to progressively enhance a site, even when it is poorly implemented in one or more browsers.

I genuinely believe (speaking from extensive practical experience going back years) without the now maligned extensions, we'd have no gradients, shadows, rounded corners, transforms, transitions, opacity and so on. Long live browser extensions

42 Posted by bmeck on 23 March 2010 | Permalink

@39 Frans
Although people are noting worries about having browsers not update to specification, I think that it does not associate directly with being homogeneous (ie. having the same styling affect in this case) to the W3 spec. I could have phrased that better in my original post, however, I went on in my post about the possibility of clarifying which interpretation to fall to by default with the concept of a !vendor or something to add to css, which could be ignored if not supported.

My original intent was an attempt to express the probable desire of browsers to conform to the same standard over time, but it might take time to conform exactly. The concept of a "meta" selector akin to !important would allow defaulting to vendor implementation if the standard is not present as of yet and only enforce the browser specific implementation if specified by !vendor.

43 Posted by Ben on 23 March 2010 | Permalink

Yup, as much as it's a royal pain typing the same rule 4 times, I'm afraid I have to agree with all the opposition in the comments.

Getting rid of vendor prefixes would create more problems than it solved.

Even if we went with a generic -beta- prefix, browser makers will still want to implement rules differently in the experimental stage. So we'd just end up with

-beta-moz-grid
-beta-webkit-grid
-beta-o-grid

44 Posted by Constantine Vesna on 23 March 2010 | Permalink

-o-10-51-rc2-border-radius:
-moz-3-6-2-and-above-border-radius:
-ms-beta4-border-radius:

like this ??

jokes aside, - prefixes are meant to remove the need to support legacy sites buggy nonstandard behaviour. they should stay.

as for -beta-, it sounds redundant because using prefixed property, you already know its is beta (or alpha, sometimes)


p.s.: Your blog post is considered harmful.

45 Posted by Azat Razetdinov on 23 March 2010 | Permalink

What about adding -*-border-radius, while keeping existing prefixes? That way we will satisfy both those who care about implementation differences and those who don't.

46 Posted by fpiat on 23 March 2010 | Permalink

I have a question about my old nineties warning : "This site is optimised for Netscape Navigator".
Should I replace "Netscape" by "Firefox" (or anything else)?

47 Posted by Daniel Glazman on 23 March 2010 | Permalink

Hi ppk.

I agree (personal opinion, not CSS WG's) that there is a problem with the way we currently manage vendor prefixes. You'll find a long thread in www-style about this.

For the time being, we allow to remove prefixes the day a spec reaches CR. This is an issue because well established shipped and interoperable implementations of one given property must remain vendor-prefixed until the whole spec reaches CR... And History shows it can take years, putting a huge burden not only on web authors' shoulders but also on authoring tools' shoulders. Authoring tools don't build web pages for a single browser. So they must support all the vendor-prefixed flavors of a given property. Even if border-radius is in CR now and the prefix can be dropped, a modern authoring tool just could not forget about -*-border-radius a few months ago. Dealing with 5 different variations of the same property for one single result is insane.

Whatever is the solution we agree on in the future, we need a discussion on this topic. The current status quo has proven it's not always satisfactory. The rest of the discussion is in the WG's hands. Stay tuned.

Daniel Glazman, CSS WG Co-chair

48 Posted by MCB Web Design on 23 March 2010 | Permalink

I totally agree. "Besides, why do we need to use several declarations for obtaining one single effect? Weren’t web standards supposed to prevent that sort of thing?" hits the nail on the head.

I don't understand why browser vendors opted to apply prefixes in the first place, rather than just supporting the standards? And if it's because the specification isn't official or completed, then what's a prefix going to do to avoid buggy or soon-to-be-superseded or wrong implementations?

49 Posted by Paul on 23 March 2010 | Permalink

Actually I don't see a problem with Samsung implementing an -o- prefix property in WebKit *as long as* they fully and accurately implement the Opera-syntax they've copied.

It would be more stupid if they duplicated the same syntax with a different prefix.

50 Posted by Nicolas on 23 March 2010 | Permalink

Can't but agree with the point of this article. The web is falling back into chaos because of irresponsible decisions such as the ones described here above.
I admit that sometimes standards may limit creativity and innovation but on the long run they actually have the opposite effect.. I do think nevertheless that the W3C has its responsibility there as it is too slow to catch up with such rising features.

51 Posted by Robin Gruyters on 23 March 2010 | Permalink

As Jadet stated:
"-beta- wouldn't work since individual vendors implement unfinished standards differently."

The problem here is when you use -beta- then you need to define standards for vendors to use the 'beta' properties. If you are already defining standards for -beta- why not implement these properties right away?

In this case i disagree with you and vendors need have their own property statement for testing purposes.

On the other hand, the question you could ask is should a developer be using these test properties anyway?