High Quality Visuals for Pinned Sites in Windows 8

Pinned Sites in Windows 8 describes how site developers can provide a site icon (favicon) for their sites’ pinned site tiles on the Windows 8 Start screen. Many of you shared feedback that you’d like to provide higher-resolution visuals to better depict your site brand on your users’ pinned site tiles. In Windows 8 Release Preview, you can to do that: we’ve added the ability for you to provide a PNG tile image and specify the tile’s background color.

Example

Below are examples of a pinned site tile using the site’s favicon and automatically determined color (left) and high-resolution PNG with custom tile color (right):

Markup

Meta tags specify the tile’s image and background color. Example:

<meta name="msapplication-TileImage" content="images/benthepcguy-144.png"/>

<meta name="msapplication-TileColor" content="#d83434"/>

Tile images must be square PNGs 144px by 144px. For best results, we recommend using a transparent background, not a background that matches the tile’s color. The tile color can be specified as a hex RGB color using CSS’s #rrggbb notation, via CSS color names, or by the CSS rgb() function.
See this behavior in action on our updated Fresh Tweets demo.
Note: IE10 only downloads the tile image when the user pins the site to his or her Start screen so sites don’t incur additional bandwidth costs.

Conclusion

Internet Explorer 10 enables Web developers to create high-quality site-centric visuals for pinned site tiles, allowing sites’ brands to be better reflected on the Windows 8 Start screen and look more visually integrated with the rest of the app and content tiles. Developers need provide only one high-quality icon that Windows 8 will scale as needed for devices running at different resolutions.
Sites can also share notifications and offer jump lists for quickly navigating around the site. See Pinned Sites in Windows 8 for how.
We look forward to you adding these simple features to your Web site to maximize their impact in Windows 8.
—Rahul Lalmalani, Program Manager, Internet Explorer

Moving the Stable Web Forward in IE10 Release Preview

7 days ago

• 45

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 and

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:

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

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:

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.

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

-ms-transform: rotate(30deg);

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

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

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.

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