(note: this article was previously published in French and translated by Nicolas Hoffmann, Goulven Champenois and Stéphane Deschamps - if you have any feedback on the translation please let us know)
Several browser makers recently announced plans to support other vendor prefixes than their own, causing quite a stir in the Web community. Several voiced their concern, including a callout by Daniel Glazman, that we translated in French here on OpenWeb, to alert them on what was happening.
Let’s recap what vendor prefixes are, how they work and why they matter.
Why were they created?
Vendor prefixes allow browser makers to experiment with technology without overloading the final vocabulary. Browser makers used to implement and release custom capabilities in the wild, sometimes with the same name but with a different result. Vendor prefixes are a simple mechanism to prevent this kind of situation from happening ever again.
How it works: browser makers release builds containing non-standardized properties, prefixed. Testing in the wild uncovers issues and use cases which are fed back to the W3C, sometimes leading to refinements. Once the property is at Candidate Recommendation stage, browsers are supposed to support only the unprefixed property.
However several things derailed this process, causing the use of prefixes on production sites:
- Implementation of some properties was relatively stable, it would have been a shame not to enjoy the benefits they bring straight away.
- The standardization process is much slower than the pace at which browsers innovate.
- This innovation race attracts web designers and many other Web makers: it is devilishly tempting to enjoy all these beautiful things!
Production sites using vendor prefixes don’t always do it right however.
Errors that were made
Not using all prefixes
Each rendering engine has its own vendor prefix, the main ones being:
-
-o-for Opera/Presto, -
-moz-for Firefox and Gecko-based browsers, -
-ms-for Microsoft, -
-webkit-for WebKit browsers: Chrome, Safari, etc.
Some lesser-known prefixes:
-
-mso-for Microsoft Office, -
-xv-Opera Software (voice), -
-atsc-Advanced Television Standards Committee, -
-wap-The WAP Forum, -
-khtml-for Konqueror browser, -
-apple-Apple, -
-prince-YesLogic, -
-ah-Antenna House, -
-hp-Hewlett Packard, -
-ro-Real Objects, -
-rim-Research In Motion, -
-tc-Tall Components.
When one or more prefixes are missing, the website looks inferior in the browsers that need this prefix, even if they do support the properties!
This is bad for those using this browser, and also for browser makers: when websites seem broken or non-working, people may wrongly believe their browser to be outdated or buggy.
If you use non-standard properties, you should have a very good reason for omitting the prefixed version of any property. Actually, the only reason for so doing is when said property is badly supported. Otherwise, why would you knowingly degrade the experience for some browsers?
Aside: many tutorials on new CSS3 properties forget to stress that these properties are not yet standardized, or very experimental. They also forget to mention that all prefixes must be used. If you come across such tutorials, do not hesitate to remind the authors or even send code fixes.
Using browser-specific properties
Some implementations of experimental properties are exclusive to rendering engines. People sometimes incorrectly refer to them as CSS3, but they are not part of this standard.
Use tools like Can I Use to know which browser and version supports any given property.
Please keep in mind these properties should be considered bonuses, and certainly not a way to discriminate browsers... and users.
Limiting to certain browsers
Browser-sniffing is rather extreme, but unfortunately does exist. It’s generally a bad idea because it is easy spoofing user-agent strings, and because such scripts need to be constantly tested and maintained because user-agent strings are an ever-changing mess.
Remember: there’s no perfect and future-proof way of detecting browsers, and browser market shares fluctuate; restricting a website or service to a single browser is a highly risky bet.
We’re not trying to blame people who make this choice, but remember that Web universality is a principle, not an option.
Problems and questionning
Using prefixed properties is not necessarily a bad thing. It allows building complex effects without using images, and simplifies development in some cases. Just keep in mind the following ideas.
Stability
Prefixed properties are experimental implementations. Syntax is subject to change in case a better solution is found.
As an example the syntax for linear gradients, first proposed by Apple, has evolved during the standardization process from:
background-image: -webkit-gradient(linear, left bottom, left top, color-stop(0.04, rgb(210,245,238)), color-stop(0.55, rgb(0,8,13)) );to
background-image: -webkit-linear-gradient(to bottom, rgb(210,245,238) 4%, rgb(0,8,13) 55%);Compatibility
These properties being unstable, future changes to the website and compatibility with older versions can prove cumbersome.
To ensure these, you might need a way to list all syntaxes with all prefixes for all browsers at any time of the project. On very experimental implementations, this may prove very complicated and hard to maintain through lack of time or budget.
You should therefore make sure that experimental implementation and syntax are relatively stable before using them on production sites. Which is quite paradoxical: you rely on the stability of an experimental implementation!
You need to constantly keep on top of how browsers implement these properties and their standardization process. Tools like "Can I Use" also indicate which stage of the standardization process a given CSS property is in.
The right way of working with relatively stable properties is to list all prefixed versions, and add the unprefixed syntax at the end. That way current browsers can use the prefixed version, and when browsers recognize the unprefixed property it will override the cascade.
Example:
background: #eee; /* fallback */
background: -moz-linear-gradient(top, #eee 0%, #bbb 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#eee), color-stop(100%,#bbb)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top, #eee 0%,#bbb 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, #eee 0%,#bbb 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, #eee 0%,#bbb 100%); /* IE10+ */
background: linear-gradient(to bottom, #eee 0%,#bbb 100%); /* W3C */Note: this example was generated by Ultimate CSS Gradient Generator.
You should evaluate the risk of a change in syntax. Major browser makers may currently agree on one common syntax, but until it is a Candidate Recommendation there’s no guarantee that it’ll always be the case.
Conclusion
You can use prefixes in production, as long as you evaluate the maintenance and durability costs. And you need to take precautions: do not depend on them for critical features, include all prefixes where the browser implementation is correct, and place the non-prefixed version at the end.
Keep in mind that you might need to go back and edit a production site CSS, even if all signals are go for the use of a given property. Remember that properties may evolve at any time until they’ve reached Candidate Recommendation.
Using prefixed properties is not trivial: it entails liability. It’s all connected: bad decisions at the project level can cause changes and drastic decisions to be necessary later on that impact everyone, browser makers, the W3C standardization process, site creators and internet users. Let’s all take care not to break the system that benefits everyone.
Using prefixes in production has its perks but should not violate the founding principle of the Web: allow access to everyone, regardless of software, hardware, and personal circumstances.
Your comments
Follow the comments:
|
