By Craig Buckler

12 CSS3 Vendor Prefix Crisis Myths

By Craig Buckler

CSS3 vendor prefixes and the impending apocalypse has been discussed at length on SitePoint since early 2012:

The issues are widely misunderstood — which is why we find ourselves in this mess. Hopefully, this article will shatter several vendor prefix crisis myths…

1. The W3C Invents Standards…

It doesn’t matter whether you’re inventing a CSS3 property, a wireless network protocol, an electricity socket or a company HR policy: nothing becomes a standard until it’s been implemented.

There is a widespread mis-belief that the W3C consists of HTML5 overlords who decree rules for everyone to follow. The W3C is not and never has been a web technology innovator. Browser vendors are responsible for inventing new CSS3 properties; these only become a standard when:

  1. the property is submitted to the W3C (all vendors have representatives who belong to the organization)
  2. it’s generally agreed that it’s a good way forward
  3. at least one other vendor implements the same feature.

2. …for Vendors to Follow

If you decided to create a browser from scratch, you’d be advised to follow the W3C specifications. There’s nothing forcing to do that, but the documents define how other browsers work today. There are even documents which describe how browsers should render invalid HTML.

The specifications are a record of what’s been done — NOT what vendors must do. Once you have a working browser, you’re free to add whatever feature you like and submit it to the W3C for consideration.

3. The W3C Approval Process Takes Too Long

It takes as long as it needs.

Vendors are normally eager to seek W3C approval otherwise their efforts have been wasted. We all work on software products and know how frustrating disagreements can be, so consider how difficult it must be for five major competitors to evaluate and approve each others ideas.

However, remember that the final “W3C Recommendation” means a feature has been implemented in two or more browsers to the same level and no one has raised reasonable objections. The property may have been usable several years prior to that point.

4. CSS3 Properties Shouldn’t be Available Until They’re a Standard

Several developers have raised the notion that properties should be disabled or only present in nightly browser releases until they are standardized. Since a property must be implemented before it becomes a standard, how can you wait for the standard before implementing a property?

The point of vendor prefixes is to evaluate feature implementation. If the feature was hidden in some way, it would receive little attention, evaluation would take longer and it wouldn’t become a W3C Recommendation in your lifetime.

You’re can wait for a property to become a standard, but…

  • You’ll be missing out on some great features. border-radius has been available in all browsers without prefixes for a while, yet the CSS Backgrounds and Borders Module Level 3 hasn’t reached the final W3C recommendation stage. You better go back to image slicing.
  • Once a property becomes a standard, there’s no guarantee it’ll be available everywhere. Most browsers are yet to implement all CSS2.1 features — and they’ve had 13 years to do it.

5. Vendor Prefixes == Beta Software

Their is a widespread belief that vendor prefixes are comparable with beta software. It leads to the conclusion that prefixed properties are not recommended for production use. This is wrong.

Beta software is released for testing purposes to determine whether features work as intended. Vendor prefixes are used to evaluate the implementation of a new feature. The difference is subtle, but it’s important to understand that:

  • While a vendor-prefixed property is pre-standard, it has been designed, documented, shared, coded and tested by the time it appears in your browser. There’s no guarantee it’ll remain the same or be implemented by other vendors, but it’s rare for a property to radically change or disappear. The worst case scenario is that the property is only ever available in one browser.
  • A vendor prefixed-property has undergone beta testing and the feature itself shouldn’t cause problems. If using a property caused a horrendous browser crash, that would be a software issue — not an issue with the property specification.
  • The only reason vendors don’t use the non-prefixed property name is to avoid implementation clashes during the early stages of vendor agreement. That might change if Florian Rivoal’s proposal is accepted.

6. Prefixes Aren’t Necessary

Eradicating prefixes doesn’t solve the vendor prefix crisis. Property differences are rare but they do occur. In those circumstances, a property would become unusable if you couldn’t distinguish between two browser implementations.

There may be better options but prefixes solve a specific problem.

7. JavaScript Doesn’t Have a Prefix Problem

JavaScript, or ECMAScript, is an internationally agreed standard. The language has barely changed since its inception and, although more radical changes are coming, the different JavaScript engines are identical. Even known bugs are replicated.

However, JavaScript isn’t the problem. When developers complain about client-side coding, it’s generally the browser APIs causing grief. Those APIs are called by JavaScript code but they’re pre-defined objects within the browser — they’re not part of the language itself.

Be aware that vendor-prefixed JavaScript APIs such as full-screen are already in-place and more are coming. However, it’s less of an issue since you can detect objects and fork accordingly. That’s not possible in CSS.

8. SASS/SCSS/LESS/Another CSS Tool can Fix Everything

There are several CSS scripting/macro languages which pre-compile rules into valid stylesheets. Most handle prefixes; you define a single standard property and the appropriate vendor prefixes are added automatically. It’s a great solution, but:

  • Not everyone can install CSS pre-compilers since you require specific server-side languages or frameworks.
  • A CSS pre-compiler is only as good as its last update. Vendor prefixes change whenever a new browser is released — the software must keep pace or it’s useless.
  • It’s another syntax to learn; many developers are happy coding raw CSS.
  • CSS pre-compilers introduce their own set of problems. Any system which generates code can get it wrong and make debugging far more difficult.

If you’re happy using a CSS toolkit that’s fine. But they’re not for everyone and only hide the vendor prefix problem. They don’t solve it.

9. Webkit Leads the Pack…

Webkit is one of the most active development groups and were first to implement some of the shinier CSS3 effects. But they don’t always lead the way:

  • The CSS3 calc() function has only just appeared in Chrome 19 but is available in Firefox has been in IE9 for more than a year without a prefix.
  • Webkit’s background gradient implementation was horrendous. The W3C members eventually settled on Mozilla’s cleaner proposal.
  • Webkit does not support the background-repeat round and space properties; they’ve been in IE9 and Opera for many months.
  • Webkit’s SVG parser has fewer features and is often slower than the other engines.

Other vendors contribute their fair share. Remember that webkit is used in Safari and Chrome; Apple and Google — the the world’s largest IT and web companies — regularly publicize new developments. The primary reason we’re in this mess is because some developers assumed webkit was the only important engine.

10. …so a Single Rendering Engine Would Solve Everything

A single rendering engine would make web developers’ lives much easier. Many have suggested that a some type of legally-enforced browser monopoly is a good idea. If you agree, remember that your wish was granted a decade ago. There was one dominant browser; coding was easy and there was little need to worry about W3C standards. IE6 was the standard. Should we ignore that historical lesson?

A single browser engine kills competition and evolution. The proposal fails to acknowledge several key issues:

  • It’s impossible to enforce legally or practically on a global level.
  • Browser vendors are competitors. Two developers will disagree about a single feature proposal; would five competing companies work in harmony on one code base? Would Microsoft, Mozilla and Opera throw away a couple of decades work to adopt Webkit?
  • Vendors have different requirements and schedules. Assume Apple required a new iPhone-specific property. Would they wait for approval from Google, Microsoft, Mozilla and Opera? Or would they fork the engine and implement it regardless? Before you knew it, we’d have five separate engines again.
  • Many have suggested that vendors could still compete on “features”. However, the browser is the engine. Vendors have been actively culling superfluous bloat to create faster, slicker applications. What are all these features vendors would compete on?
  • One engine doesn’t mean one version. Even today, Chrome’s quicker release schedule results in it having a more recent edition of webkit than Safari.

Despite having five major applications, development is easier than it’s ever been. The browser market is active, thriving and exciting again. I hope we never lose that.

11. Vendors are to Blame

Do vendors have a duty to developers? Or should their overriding concern be for millions of end users?

There have been instances when vendors have promoted prefixed properties as an HTML5 standard, but they do not purposely make our lives difficult. Prefixes solve more issues than they raise. The only reason we have a crisis now is because a subset of web developers failed to use -webkit, -moz, -ms, -o and non-prefixed CSS3 properties. It’s time to stop the whining and fix the problems in our code.

12. Prefixes Were a Stupid Idea

Vendor prefixes aren’t perfect. They are a solution which prevents two vendors implementing the same property in different ways and rendering it unusable. Perhaps they were a little naive, but it’s easy to spot drawbacks with the benefit of hindsight.

Better solutions will inevitably appear but, until then, we’re stuck with prefixes and its up to us to use them appropriately.

  • Gail H.

    This is a well-written article with a fair point. It is easy to blame the vendors for the design difficulties we all face, but it is clear that there is plenty of blame to go around, and the developers must accept their share. I guess I will continue to do what I have been doing in recent development: build up from HTML5, add CSS3, and for each “experimental” property, use all available prefixed versions, with the unprefixed version last. Use the “experimental” properties in non-critical presentation, but not in critical layout. Then cross my fingers and see what breaks when the vendors run off in random directions.

    So many design issues result from the fact that HTML5 and CSS3 are still basically static. One needs javascript to detect browser conditions and make decisions, and cookies to remember the decisions. Some decision making can be done at the server once the browser is known, but the server can’t detect the browser, and the user can defeat javascript and turn off cookies. And the site still has to work properly if he does.

    Even if there were some way for HTML or CSS to detect browser capabilities and render behavior accordingly, we’d still have the same problem: each vendor would handle the process differently, and the guessing games would continue. So what we always seem to be left with is: build a basic site, add bells and whistles until each browser breaks. When none of the browsers implement a particular instruction, you know you’re done. For now.

  • Francesco

    Great post as usual!

    I just wanted to point out that you don’t “require specific server-side languages or frameworks” for pre-compilers to work. At least, not all of them. Well, at least SASS/SCSS, not sure about the others (but I think LESS too can work like that). You only need to install Ruby on *your* computer, not the server. It took me five minutes to set it up.

    Of course I shouldn’t talk since I’ve never actually started using it (but I will!) and it doesn’t invalidate your other points, of course!

    • Thanks Francesco.

      OK, so perhaps you don’t always need to install a language/framework on the server but, if not, you’ll certainly need one on your development PC. Either way, that’s not always practical for everyone.

  • Interesting article, thanks for sharing it with us. I definitely learned a lot about w3c and vendor prefixes that I didn’t know before.

  • Hi Craig,

    This caught my eye: “The W3C is not and never has been a web technology innovator. ”

    There are numerous instances where people on the W3C staff led the creation of new Web technology. CSS and Semantic Web come to mind in particular.

    I think it is important to acknowledge that Web innovations come from lots of sources, including, but not limited to, browser makers.

    Thanks for making the point that people should use features even before they appear in a Recommendation (we appreciate the feedback during development), and that people should be aware of levels of stability in the spec and interop of implementations.



    • Thanks Ian. That’s a fair comment, although nothing becomes reality until browser vendors implement a feature. But it’s great that anyone can influence the future direction of the web.

  • I think vendor prefixes are great idea.. What better way there is to test new (complicated) features in wide userbase? None in my opinion…

  • Dean

    Your comment “A CSS pre-compiler is only as good as its last update. Vendor prefixes change whenever a new browser is released – the software must keep pace or it’s useless.” misses the mark doesn’t it? The software doesn’t decide what vendor prefixes are to be used – the developer describes them in a mixin. It’s up to the developer to keep his/her CSS relevant, regardless of whether a pre-processor was used to create it.

    Also, on the same point: “Any system which generates code can get it wrong and make debugging far more difficult.” Not really – SASS won’t output anything unless the rendered CSS is correct, so debugging is easy. It can be less obvious how to debug code created by SASS using eg. firebug because say a hex colour value may have been calculated and not explicitly stated, but if you don’t know how to debug CSS by relating the HTML element back to the CSS you created you probably wouldn’t last very long as a developer anyway.

    • Thanks Dean,

      There are pre-compilers, pre-compilers and pre-compilers. There’s some common functionality, but they’re ultimately different pieces of software doing a similar job in different ways. Some add prefixes automatically, some expect mixins or other methods. Whatever the case, that software must keep pace with CSS technologies.

      How does SASS know the CSS is “correct”? It runs software algorithms which check syntax, but cannot possibly understand contexts or what the programmer meant. There’s a translation step between your code and the final stylesheet. If that CSS is wrong, you may be able to find where it exists but that may bear no relation to its location in your pre-compiled code. You may even find it difficult to fix generated code.

      In reality, pre-compilers are generally reliable, but I’m always wary about code which translates other code into different code!

  • Anonymous

    The blog ate the HTML tag characters I used (great server software, congratulations!).

    The browser would apply those rules, in order:
    1. If there is a “-myprefix-property” property, use its value
    2. If there is a “property” property, use its value
    3. If there is a “-anotherprefix-property” property, use its value (if there’s more than one, break ties with some criteria)

  • how can you wait for the standard before implementing a property?
    really, how?

  • People don’t like to read: “I agree” or “Well done” in a comment. They are right, Especially if there is no other information in a comment. But once I want to say thank you for all of your well written posts. To many of them I can say “I agree”, because I already knew what you are writing about. But I am happy someone spreads the message and clears up misunderstandings.
    Sometimes of course I find something new for me, too!
    So please don’t blame me for saying once and for ever: I agree, well done and – – – thanks for sharing!

Get the latest in Front-end, once a week, for free.