IE9, Vendor Prefixes, and Developers
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
Comments
Anonymous
November 15, 2010
way cool stuff! Glad to hear that all the innerHTML bugs have been fixed allowing you guys time to mess around with the fancy new stuff. oh wait, innerHTML isn't fixed in IE yet! what gives?Anonymous
November 15, 2010
Maybe prefixed CSS animations or transitions now? Pretty please? (way cool: come on. Either MS knows the innerHTML behavior changes are a big problem and they're working on it, or they've made a design decision that the current behavior is what they want. Can't guess which since you don't describe which behaviors you don't like. Either way, I doubt Microsoft is on the verge of making your changes and just waiting for a snarky blog comment to push them over the edge.)Anonymous
November 15, 2010
Why don't the dev tools allow you to see styles with browser prefices (except ms)?Anonymous
November 15, 2010
@way cool the changes that have already been made to IE9's innerhtml have been discussed in a previous blog post blogs.msdn.com/.../interoperable-html-parsing-in-ie9.aspxAnonymous
November 15, 2010
Can we have localStorage working before the final release please? While I'm excited about having a very standards-compliant version of IE for a change, it's the related technologies of HTML5 which myself and others want to use. Without localStorage and some of the other things IE9 doesn't support (see html5test.org) that we need. Otherwise, we'll still have to code 2 versions - one for IE, and one for everything else.Anonymous
November 15, 2010
Are the 2d transformations properties accessible through the DOM and if so, do these properties also have a prefix?Anonymous
November 15, 2010
way cool, I regretely have to say: IT would be better if IE9 was just BUG FIXES...and then in IE10 add CSS3, HTML5, but I understand that no one user, in today market of browsers, will be satisfied with just that. Thanks IE Team!Anonymous
November 15, 2010
This is a rather handy JS library that allows you to use the W3C attribute name and have it automatically translated into the vendor prefixed version as needed, for those where the syntax is the same: github.com/.../jQuery-Css3-Finalize See github.com/.../jquery.css3finalize.js for which attributes are supported (it doesn't translate different gradient syntaxes, etc)Anonymous
November 15, 2010
@Alexandre Bars: the "bug fix" release was IE8.Anonymous
November 15, 2010
@AMWJ: Same happens with every browser's dev tools (Firebug, Dragonfly, Webkit dev tools too...). They only show the rules they understand, and other browsers' prefixes is not something they understand, which is kinda the whole point :PAnonymous
November 15, 2010
I use middleware (LessCSS or my own solution) to be able to use the non-prefixed version and have it translated into whatever I currently deem best. It's a workaround, but it works fairly well.Anonymous
November 15, 2010
The comment has been removedAnonymous
November 15, 2010
While I love the topic of this post, the reference to CSS gradients worries me as I would absolutely love it to be supported in some way. After text-shadow that is my #2 hope out of IE9 that I haven't already seen (heck, I'd be okay with no CSS transforms if it meant we got those). I'm aware of the widly different syntaxes so I will understand if they don't make it, but I did have hope. =/Anonymous
November 16, 2010
@Charlie Starting with Platform Preview 5 (Beta 1), innerHTML is supported on table and select elements - unfortunately, the current implementation is worse than a simple failure of the setter. But the issues are reported ad reproduced. I'm sure something that big won't be regressed in the final. See issues # 600942 - connect.microsoft.com/.../600942 and # 571341 - connect.microsoft.com/.../571341 To be hinest, I don't know what I should do with the fourth bug of innerHTML you mentioned. The WebBugTracker's description contradicts the code examples. Without a good explanation and without a testcase that makes the issue reproducable for anyone (I personally tried about 15 minutes playing around the WBT code to reproduce the issue - but failed), how can you expect the bug to be fixed? @Stifu: Actually I think IE7 was the bugfix release, IE8 was the let's try something new release and IE9 will be the something new actually worked out release.Anonymous
November 16, 2010
@the_dees: what significant "new" thing did IE8 try, really[1]? Unless seriously trying to support CSS 2.1 is to be considered something "new" rather than a "fix". [1] Web slices and stuff don't countAnonymous
November 16, 2010
@Stifu: IE8 brought stricter Jscript parsing and compilation, which made it crash on code pieces that it couldn't even reach before. Oh wait... Never mind. I wonder, now that Firefox 4 beta 7 brings 'full' hardware acceleration (on XP and Mac, too) switched on by default, and finally enabled JägerMonkey (tripling its Javascript speed over current 3.6.12), will we see any more IE benches on these pages? Or will this speed, features and compatibility improvements game continue? I won't complain if it does :DAnonymous
November 16, 2010
@Stephen Orr: IE8 introduced support for localStorage, and its availability continues unchanged in IE9.Anonymous
November 16, 2010
@Marcus Tucker, Vendor prefix detection doesn't require browser UA sniffing (which is what jQuery.browser does). perfectionkills.com/feature-testing-css-properties @IE team, I'm thrilled about the improvements in IE 9. But I'm even more thrilled with the amount of information you're putting out about the browser development process, why certain choices were made, and so on. This kind of transparency gives web developers a first chance to see that Microsoft really is interested in developing a good browser that competes on level ground. Thanks for keeping the communication coming.Anonymous
November 17, 2010
Html5 Test: Firefox 3.6.12 -> 140 IE 9 Beta -> 96 !!! http://html5test.com/Anonymous
November 17, 2010
I'm all for vendor prefixes and it's a good sign on adding support for unfinished specs while still giving web designers the ability to try things out. @way cool The innerHTML method IS a bug. Stick to using the DOM.Anonymous
November 17, 2010
Stifu, I like IE, but please before say, have some reflect: http://jhop.me/ie8-bugsAnonymous
November 22, 2010
Browser prefixes in IE are different than other browers. Why is it always IE that behaves differently? Blog here: http://j.mp/hyye0k