Blogs

7 Solutions to the CSS3 Vendor Prefix Crisis

Craig Buckler
Share

As we reported last week Mozilla, Microsoft and Opera have become frustrated with sites which only target -webkit CSS3 properties. It makes their browser look bad even when it implements identical or better technology. To solve the issue, they propose adding -webkit prefix support to the non-webkit browsers.

While this is largely a marketing decision, it’s a real problem. The solution appalls many web developers but we deserve our share of the blame. In this article we’ll discuss the options, pros and cons.

1. Nothing Changes

Assume nothing is done to solve the browser prefix problem.

PROS

  • Browsers continue to implement their own prefixes which you are free to use or ignore.
  • There’s nothing new to learn or test.
  • It feels right and the decision will please the majority of web developers.

CONS

  • We retain the four prefixed and one standard property. Stylesheets are larger than necessary and difficult to test.
  • Lazier or less experienced developers will continue to target webkit browsers only.
  • Chrome and Safari’s market share could rise to a point which makes other browsers redundant. We return to the days of single browser engine and innovation stagnates. The dark days of IE6-like dominance return.
  • Microsoft, Mozilla and Opera consider this to be a real problem: doing nothing is not an option.

2. Non-Webkit Browsers Support the Webkit Prefix

Assume IE, Firefox and Opera support webkit-prefixed properties.

Microsoft had already implemented -webkit-text-size-adjust in the mobile version of IE. While it’s a non-standard property for Safari (there’s no text-size-adjust), they listened to community feedback and pulled support. That’s unlikely to happen again if Mozilla or Opera start adding webkit properties to their engines.

PROS

  • It’s a quick and dirty solution which allows non-webkit browsers to render as well as Chrome or Safari.
  • There’s no need for developers to update their websites.
  • -webkit will become the dominant prefix; using -moz, -ms or -o will become unnecessary and CSS file sizes will reduce
  • It prevents webkit, Google and Apple becoming too powerful. If another vendor disagrees with an implementation, they can simply break it or provide an alternative. Developers may not be able to use the property in any browser.

CONS

  • It feels wrong: one browser should not need to masquerade as another.
  • It rewards sloppy development practices.
  • Differing browser implementations will make some properties unusable.
  • If developers retain webkit properties which fail in other browsers, more users will switch to Chrome and Safari. Other vendors will become increasingly irrelevant.

3. All Browsers Use a -beta Prefix

Rather than separate prefixes, assume every browser implemented the same -beta prefix.

PROS

  • Just one prefix to learn and use.
  • Stylesheet file sizes are reduced.
  • The property is obviously experimental; developers will be more cautious about using it.

CONS

  • As a solution, it’s little different to every vendor adopting the -webkit prefix.
  • Differing browser implementations may make some properties unusable.
  • Vendors are unlikely to remove their own prefixes; the situation won’t change.

4. Experimental CSS Properties Only Appear in Beta Browsers

Assume prefixed properties are abolished in all browsers. Newer experimental properties would only be present in nightly and beta releases — and they would not require a prefix.

PROS

  • It becomes impossible for developers to use prefixed code or target specific browsers in production websites.
  • Webkit-only sites are punished accordingly.
  • We all work to final standards — not future ones.

CONS

  • Far fewer developers will use and test experimental properties. It could lead to buggier implementations.
  • New properties may take several years to become standardized. Are we prepared to wait?
  • It’ll never happen. If a single vendor chooses to keep prefixes in their main release, they all will.

5. Vendor Prefixes are Dropped Following Final Implementation

Once a property is stable and implemented without a prefix, all previous prefixed versions are removed from the browser.

PROS

  • It’s a logical solution.
  • It removes unnecessary code. Library bloat is reduced and browsers become leaner and faster.
  • It rewards good development practices and punishes the bad.

CONS

  • It offers no immediate resolution for sites which only target webkit browsers.
  • It will break sites overnight — vendors will be reluctant to implement the policy.
  • Properties can take years to reach standardization and browser implementation schedules differ. Prefixes will break at different times so ongoing site testing and maintenance is required.

6. The W3C Agreement Process Becomes Faster

Assume the W3C adopt quicker methods of standardization and publish schedules detailing when a property is expected to reach maturity.

PROS

  • The existing process is too slow.
  • Developers will know when the final property can be used.
  • There’s less chance for vendor prefixes to gain widespread adoption.

CONS

  • The process is not intentionally slow. There will always be practical and logistical problems to overcome.
  • Vendors work at different speeds and it’s impossible to accurately estimate delivery times.
  • A faster approval process could lead to poorer implementations which negates the point of having a standardization process.

7. Better Evangelism and More Education in the Developer Community

We would not be in this mess if developers wrote cross-browser code and understood best-practice techniques.

PROS

  • It’s a good solution which we can implement today.
  • Anyone demonstrating example code with prefixed properties can provide browser support information with strong disclaimers.
  • Everyone can help. Fix your own code and contact sites which are not cross-browser compatible.

CONS

  • There’s no guarantee evangelists and developers will change their attitude.
  • Is it too late? Best-practice techniques are published but ignored.
  • There’s no definitive central information repository.
  • There will always be new, ignorant and sloppy developers. No one can become an expert overnight.

There’s no single solution to the vendor prefix problem. Personally, I favor a quicker W3C process, dropping prefixes after implementation and better evangelism. But those require a major shift in mindset rather than technical changes.

Ultimately, developers caused this problem: it’s up to us to fix it. There won’t be an issue if we shun prefixed properties or use correct cross-browser fallbacks. If we don’t, there’s a risk the CSS3 properties we rely on today won’t work tomorrow.