Jump to main navigation, main content

Archived entry | Matt Wilcox .net

Vendor Prefixes, the wider problem.

If you haven’t read the current furore over Opera’s implementing support for certain -webkit- vendor prefixes, be sure to read this excellent summary before reading on. I’m not going to wade through establishing context in this post.

What’s the real problem?

Vendor prefixes were always a bad solution, as pointed out by a few people at the time. Why? Because in reality any vendor’s goal is to increase their user base, whether for business reasons (more users = more money) or for influence (more users = more sway in decision making circles, regardless of anything else). Given the importance of user base size, any vendor’s secondary goal is to stop loss from their existing user base. No one wants less profit or less influence. Only after looking after the bean-counting does a vendor’s goals move to championing standards or any other wider context issue. This is a reality, and this is why vendor prefixes were always going to be a serious problem leading to its own destruction.

The major symptom at the moment is presented as this: Opera users are unable to use some poorly coded websites that are omitting -o- prefixes and instead using only -webkit- prefixes. Personally, I am hard pushed to believe this is actually an accessibility problem, and more inclined to believe that it’s a convenient pretext for shoe-horning fancy effects into Opera - people like shiny effects, Opera can render them, this is a short-cut to getting them displaying even when lazy developers haven’t told Opera to render them.

Regardless, Opera doing this has a number of effects:

  1. Opera users now get to see gradients, rounded corners, and the like
  2. The standards process is broken because prefixes are now a lie
  3. Incompetent web developers may cheerily carry on being incompetent and Opera will fix their sloppiness for them, masking their ineptitude from everyone.

The first point is a net win for Opera users, and thus a net win for Opera; who get to keep more users. The second point is a problem for everyone who isn’t Opera, as I tweeted:

Why? Because we’ve been down this road before with User Agents, which were subverted for exactly the same reasons and have lead to a complete and utter cluster-fuck situation where almost any browser reports itself to a server as being every other browser in addition to the one it really is.

The third point is my major concern, but it is in keeping with how the web has been designed since its inception. It does not punish lack of skill, it masks it.

Ok, so what would I do?

Firstly, I’ll emphasise something: not having a better solution in no way detracts from the validity of a problem. People that retort “do you have a better idea” and dismiss objections if not accompanied by a solution do themselves a diservice.

What would I do? Nothing with the Opera engine. I’d leave it all as it is - mainly because I am unconvinced there’s a genuine accessibility problem with vendor prefixes. I strongly suspect the “real motivation” is a market-share problem for Opera, and in the wider context it’s a “for fucks sake, when will developers learn to code responsibly” problem. And in an implementation context it’s a “Hey, W3C, vendor prefixes failed; how do we do this better?” problem.

As a web user I don’t give a shit about the first problem, though obviously as an Opera user I would (to be clear, I code my site’s properly and test in Opera, I care that my site’s work in it, but I don’t care about Opera’s business worries). The web will be around forever, Opera won’t. No specific vendor is likely to outlast the web. My eye is on the long-term not the short-term. With that in mind I’d go back to the W3C and sort out a better solution. No it isn’t easy. No I don’t know what that might be. No that doesn’t make it wishful thinking or vapid as an idea.

What Opera is doing is at best an interim solution, which I’d be mildly more comfortable with if the specs said that any browser could legally interpret any vendor prefix as long as the vendor prefix has an identical implementation and effect as a W3C recommended property. That is more or less exactly what Opera are doing - but this is not a genuine fix for anything. It’s a patch-up. It won’t change anything other than allow vendor prefix abuse to continue longer than it otherwise would, weaken the vendor-prefix use case, and cause confusion the longer it applies. It’s a band-aid while we look for real medicine.


I don’t envy Opera. I understand why they’re going down this route. I still believe it is wrong. I’m not convinced the sky will fall in - but nor am I convinced it was to begin with. I think the short-term observable effects will be rather nice for Opera users and almost negligible for everyone else. But I also think the long term effects will start to pile up and get worse - just like User Agent String did.


skip to comment form
  1. Richard Lyon posted 9hrs, 50min, 6sec after the entry and said:

    Couldn't say this on twitter without spamming, but my thoughts on how browsers should implement vendor prefixes is that the following should work in all browsers:

    border-radius: 30px;

    If for some reason a specific browser needs to be overriden then they should treat their own prefix as more important:

    border-radius: 30px;
    -o-border-radius: 25px;

    This gets more complicated with stuff where the value isn't simple (gradients!) - if the format isn't clear then the standard shouldn't even be published, let alone partially implemented.

    Perhaps we have got the vendor prefix thing entirely wrong from the start? Instead of only having prefixes for experimental properties, wouldn't it be lovely to have them for every property in CSS?

    body {
    background: #000;
    color: #fff;
    -ie-color: #f00; /* because who cares about IE? */

    Either way, vendors implementing each other's prefixes is bloody stupid for a short-term win.

From the archives

Other enteries filed under:

My Two Cents

Web Development

Site information

Built with valid XHTML and CSS, designed with web standards and accessibility in mind. Best viewed in a modern browser [Firefox, Safari, Opera]

This domain and all content is a copy of my old website, for historical purposes only.