Moving the Stable Web Forward in IE10 Release Preview

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:

• Are stable, that is, there were no recent additions or changes and no renaming or major changes are expected;
• Are supported by at least two browsers other than IE10;
• Are interoperable across all these browsers for the features’ core use cases;
• Are already used on the Web, including in their unprefixed form; and
• Reached Candidate Recommendation since Windows 8 Consumer Preview or are likely to become Candidate Recommendations in 2012.

The following W3C draft standard features match these criteria and IE10 now supports them in their unprefixed form:

• Gradients (CSS Image Values and Replaced Content)
• CSS Animations
• CSS Transitions
• CSS Transforms
• font-feature-settings property (CSS Fonts)
• Indexed Database API
• Timing control for script-based animations (requestAnimationFrame)

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).

IE10 also supports the following W3C draft standards in vendor-prefixed form. We believe these drafts do not yet meet the criteria listed above:

• CSS Flexible Box Layout
• CSS Grid Layout
• CSS Regions
• CSS Exclusions and Shapes
• CSS Device Adaptation

From Experimental to Stable

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.

New platform APIs such as window.requestAnimationFrame() are likewise currently invoked as window.mozRequestAnimationFrame(), window.webkitRequestAnimationFrame(), or 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:

• Allow the specification to evolve: without prefixes web content written for the earliest implementation(s) could constrain the editor(s) and make useful additions or changes difficult or even impossible, and
• Segregate experimental implementations: the bugs or choice of draft version of a particular browser have no impact on other browsers.
• Style sheet documentation: the vendor-specific dependencies of a style sheet are explicitly documented

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>.

The Web’s Best Practices

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:

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:

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.

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.

Many transition effects involve CSS Transforms, tutorials for which also frequently declare unprefixed transform properties.

Finishing the Specs

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.)

What It Means For Your Code

CSS gradients

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:

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:

A future blog post will cover IE10’s support for CSS gradients in more detail.

Cascading and the CSS Object Model

The cascade will resolve prefixed CSS properties as expected; given the following rule (notice the higher rotation angle in the unprefixed declaration):

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.

Likewise, setting element.style.transform will also set element.style.msTransform and vice-versa.

Serialization of property names

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:

IE10 Release Preview will serialize the value of both style.msTransitionProperty and style.transitionProperty as ‘transform’. Note that the original prefix is not preserved.

This is also true for the propertyName property of transition events.

Animation and Transition event type names

IE10 Release Preview allows the registration of Animation and Transition event listeners using both prefixed and unprefixed names i.e. the following are equivalent:

But IE10 Release Preview will always return an unprefixed name in the type property of the event object.

What’s Next

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