The Sixth Platform Preview of IE9 includes support for CSS3 2D Transforms. Similar to the use of “ms” in the Web Timing APIs, the 2D Transforms properties begin with –ms: -ms-transform and –ms-transform-origin. This post explains the purpose of vendor prefixes, how we decide when to use vendor prefixes, and how we recommend developers treat these properties.
The purpose of vendor prefixes
Vendor prefixes are a mechanism that several browsers have used for handling timing conflicts between implementations and specifications.
When writing a specification, working groups need feedback from early implementations. However, they also need freedom to change the spec without being locked into the behavior of an early implementation.
Vendor prefixes exist to balance these needs by providing browsers a clear way to tell developers a feature is experimental. Developers should expect these features might work differently across browsers. Behavior could change significantly in future releases.
Vendor prefixes are crucial to achieving the goal of making the same markup, CSS, and script work across browsers. They bridge the gap between early implementations of the early specification and a stable implementation of a stable specification. Without them, browsers might support different versions of the same specification, leaving developers to deal with the inconsistent results.
Meanwhile, everyone involved in the standardization process works together to stabilize the specification so all browsers can remove the prefix as soon as possible.
When we use vendor prefixes
If a property, method, or object’s specification is likely to change enough to make future updates not backward compatible, IE uses the vendor prefix. Convention is to use a prefix until the specification is a Candidate Recommendation (read this post for an outline of the full process). When we added border-radius, we decided not to use –ms as the specification was a Candidate Recommendation at the time. The full module is again a Working Draft to resolve box-shadow issues but border-radius is still at Candidate Recommendation stability. Other browsers either already support the unprefixed version or will in an upcoming release.
The 2D Transforms module, however, is in a different position. The specification is a Working Draft as the group continues to discuss issues. As a result, all browsers support these properties with a vendor prefix.
How developers should use properties with vendor prefixes
Vendor prefixes indicate an experimental implementation. If you’re interested in using an experimental feature in production code, it’s important you:
- Only use properties you can test. This sounds obvious, but in an attempt to “future proof” your site, it can be tempting to add the prefixed version for all browsers or add the unprefixed version before any browser supports it. Doing this puts your site at risk because with experimental features there’s no expectation that the next implementation will work like the current one or that the future unprefixed version will work like the current prefixed one.
- Test your site as browsers update. Again, the behavior is likely to change, so you need to stay up-to-date as browsers change.
Take CSS3 Gradients as an example. When Mozilla and WebKit introduced the feature, each used a different syntax and significant feedback exists on the editor’s draft. As a developer, guessing at future behavior only puts your site at risk of behaving unexpectedly as browsers respond to changes in the specification.
Using Vendor Prefixes in Samples and Tests
Vendor prefixes create a challenge for those trying to test implementations since you can’t have the same test code run in all browsers. As a result, the W3C does not accept test cases that use vendor prefixes.
Developers creating samples with 2D transforms will need to update their CSS to use the appropriate vendor prefixes. As you come across these, some may not work even in the latest IE9 Platform Preview because the author has yet to update the page.
We’re excited to have 2D Transforms in IE9 so web developers can learn, experiment, and provide feedback. We’re even more excited for reaching consensus on the specification and making this another dependable part of the interoperable web platform.
John Hrvatin
Lead Program Manager, Internet Explorer