As part of Windows 8 Release Preview planning, we reviewed all the W3C draft standards supported by IE10. In particular, we looked for those specifications that:
The following W3C draft standard features match these criteria and IE10 now supports them in their unprefixed form:
font-feature-settings
For compatibility with sites and apps developed using the Windows 8 Consumer Preview, IE10 also supports these standards in their vendor-prefixed form using the Microsoft vendor prefixes (‑ms‑/ms).
‑ms‑/ms
IE10 also supports the following W3C draft standards in vendor-prefixed form. We believe these drafts do not yet meet the criteria listed above:
When Web browsers implement emerging standards they do so by marking the new features with their own vendor prefix: a style property prefixed with ‑moz‑ indicates an experimental CSS feature in Mozilla's Firefox, ‑ms‑ means the same for Microsoft’s Internet Explorer, ‑o‑ for Opera, and ‑webkit‑ for WebKit-based browsers including Google’s Chrome and Apple’s Safari. The features’ object model equivalents are similarly prefixed.
‑moz‑
‑ms‑
‑o‑
‑webkit‑
New platform APIs such as window.requestAnimationFrame() are likewise currently invoked as window.mozRequestAnimationFrame(), window.webkitRequestAnimationFrame(), or window.msRequestAnimationFrame().
window.requestAnimationFrame()
window.mozRequestAnimationFrame()
window.webkitRequestAnimationFrame()
window.msRequestAnimationFrame()
Browser vendors generally drop their prefix once the corresponding specification reaches the Candidate Recommendation stage. This naming convention has a number of objectives, among which:
Other standards may not rely on vendor prefixes at all. For instance, browser vendors never prefixed the new HTML elements introduced by the HTML5 specification such as <canvas> and <video>.
In practice, there comes a time when several browsers support the same draft feature in an interoperable manner. As a result, Web developers find themselves writing declarations such as:
-webkit-transform: rotate(30deg); -moz-transform: rotate(30deg); -ms-transform: rotate(30deg); -o-transform: rotate(30deg);
-webkit-transform: rotate(30deg);
-moz-transform: rotate(30deg);
-ms-transform: rotate(30deg);
-o-transform: rotate(30deg);
After copy and pasting this pattern a number of times, many developers assume the forthcoming W3C standard will be backward compatible with today’s Web. They proceed to “future-proof” their style sheets by adding an unprefixed version of the property:
-webkit-transform: rotate(30deg); -moz-transform: rotate(30deg); -ms-transform: rotate(30deg); -o-transform: rotate(30deg); transform: rotate(30deg);
transform: rotate(30deg);
From a web developer’s point of view, the above set of declarations is now ready for future browsers that support unprefixed CSS Transforms.
Past standard features have in fact validated this pragmatic assumption. When IE9 added support for the unprefixed border-radius property in its first Platform Preview, our team saw the feature “light up” across many sites due to the future-proofed style sheets already deployed.
border-radius
A number of features are going through the same evolution now. Not only are many CSS Transitions demo pages already future proofed – see Paul Hayes’ parallax effect or Lea Verou’s animatable gallery – but open source projects such as Google’s html5slides, designers’ home pages, site logos and tutorials routinely include unprefixed transition declarations.
transition
Many transition effects involve CSS Transforms, tutorials for which also frequently declare unprefixed transform properties.
transform
Even as Web developers anticipate browser convergence in their new markup, the standardization process is far more conservative. While border-radius worked interoperably enough for thousands of Web sites, members of the CSS Working Group were busy defining the rendering of more complex cases such as the appearance of a rounded corner between two adjacent borders of variable widths and colors. Likewise, the CSS Transitions, Animations, and Transforms editors are working to specify error conditions, fix errors, or clarify less common scenarios.
While these issues must be resolved to ensure a high level of interoperability and to reach Recommendation status, relatively few of them will affect current and future content. Once a specification is stable and interoperable the web should not be held back by the last corner cases. This was not necessary for new HTML5 elements or to finalize the CSS2.1 spec, neither of which required prefixing.
While solid specifications backed up by complete public test suites are critical, requiring all Web developers to repeat the same declarations multiple times until a Candidate Recommendation is published prioritizes spec completeness over content stability.
Finishing a specification is a time-consuming effort. To take one example, CSS gradients emerged in 2008, the first Working Draft specifying an interoperable solution in 2009 and the Candidate Recommendation was published in April 2012. In the meantime, the standardized syntax became incompatible with the prefixed syntax deployed on many Web sites. The Release Preview of IE10 is the first public unprefixed implementation of the latest spec. (IE10 also supports the more interoperable prefixed version with the ‑ms‑ vendor prefix.)
While broadly interoperable, the prefixed gradient syntax supported by all modern browsers reflects a now obsolete draft version of the specification. This earlier syntax is incompatible with the current Candidate Recommendation. For example, if you have declared the following gradient:
background: -ms-linear-gradient(left, yellow, red);
Then producing the unprefixed equivalent is not simply a matter of removing the ‑ms‑ prefix. Because IE10's unprefixed linear gradient function conforms to the latest specification, it should become:
background: linear-gradient(to right, yellow, red);
A future blog post will cover IE10’s support for CSS gradients in more detail.
The cascade will resolve prefixed CSS properties as expected; given the following rule (notice the higher rotation angle in the unprefixed declaration):
-ms-transform: rotate(30deg); transform: rotate(60deg);
transform: rotate(60deg);
Your element will rotate 60 degrees: the two properties are treated as aliases of each other and the last declaration wins. Their corresponding CSSOM properties are also aliases: if you request the computed value of the transform and msTransform style properties they will both reflect the winning 60 degree transform.
msTransform
Likewise, setting element.style.transform will also set element.style.msTransform and vice-versa.
element.style.transform
element.style.msTransform
Properties such as transition-property take a list of CSS property names. For instance, to make the transform property transition over 2 seconds in IE10 Consumer Preview a developer would write:
transition-property
-ms-transition-property: -ms-transform; -ms-transition-duration: 2s;
-ms-transition-property: -ms-transform;
-ms-transition-duration: 2s;
IE10 Release Preview will serialize the value of both style.msTransitionProperty and style.transitionProperty as ‘transform’. Note that the original prefix is not preserved.
style.msTransitionProperty
style.transitionProperty
This is also true for the propertyName property of transition events.
propertyName
IE10 Release Preview allows the registration of Animation and Transition event listeners using both prefixed and unprefixed names i.e. the following are equivalent:
element.addEventListener("MSTransitionEnd", myHandler, false); element.addEventListener("transitionend", myHandler, false);
element.addEventListener("MSTransitionEnd", myHandler, false);
element.addEventListener("transitionend", myHandler, false);
But IE10 Release Preview will always return an unprefixed name in the type property of the event object.
type
We will submit new test cases to the W3C for all the features that IE10 now supports without a prefix. As Working Group members and co-editors, we will work with our colleagues to move these specifications forward to Candidate Recommendation.
We welcome feedback you have on our support for these feature and their cross-browser compatibility.
—Sylvain Galineau, Program Manager, Internet Explorer