12 CSS3 Vendor Prefix Crisis Myths

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:

the property is submitted to the W3C (all vendors have representatives who belong to the organization)
it’s generally agreed that it’s a good way forward
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.