четверг, 26 июля 2012 г.

IE10 User Agent String Update

The IE10 user agent string was originally introduced in the first platform preview of IE10. In Windows 8 Release Preview we made two additions to aid server-side feature detection.
The first addition enables detecting whether a machine has touch-capable hardware via a new Touch token. Using this token you can present a touch-friendly version of your site to users with touch-capable hardware (typically, in the case where your normal site is not touch-friendly). Keep in mind that users with touch-capable hardware may also use a mouse and keyboard. You can see where this token fits into the user agent string in the examples below.
  • IE10 on a machine without touch-capable hardware:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
  • IE10 on a machine with touch-capable hardware:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; Touch)
If you're detecting touch support client-side, do not sniff the user agent string; use navigator.msMaxTouchPoints instead. If the property exists and returns a value greater than zero, the user’s PC has touch capability. For example:
var hasTouch = navigator.msMaxTouchPoints > 0;
The second addition to the IE10 user agent string is a new architecture token for ARM devices running Windows RT. This complements the existing values for other architectures. The examples below show how this compares to a few other configurations.
  • 32-bit IE10 on 32-bit Windows:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
  • 32-bit IE10 on 64-bit Windows:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
  • 64-bit IE10 on 64-bit Windows:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64; Trident/6.0)
  • IE10 on Windows RT:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; ARM; Trident/6.0)
These additions apply to both desktop and Metro style IE10 since they expose the same platform capabilities. We recommend optimizing your site’s experience around the capabilities of the system (like Touch) through feature detection, rather than browser or environment detection. Where content depends on plug-ins, use the requiresActiveX prompt to help users switch to desktop IE10 until the content can be made plug-in free.
—Tony Ross, Program Manager, Internet Explorer

XMLHttpRequest responseXML in IE10 Release Preview

IE10 in Windows 8 Release Preview updates the responseXML from an XMLHttpRequest to return a native XML document by default. This change applies to IE10’s Standards and Quirks document modes, making them interoperable with other modern browsers and consistent with a “same markup” approach. Compatibility document modes 5, 7, 8, and 9 are unchanged.
This change may impact sites that were expecting responseXML to contain an MSXML document and depended on MSXML-specific functionality such as selectNodes. In these cases, you may request that IE10 return an MSXML by setting the responseType member of your XMLHttpRequest object to 'msxml-document'. If your code does not depend on MSXML-specific functionality, IE10’s native XML document should work for you.
Native XML support in IE9 brought DOM parity to XML and HTML and enabled XML fragments to be inserted and rendered directly within a page (even in HTML). IE9 also simplified converting between XML and DOM with the addition of DOMParser and XMLSerializer. IE10 completes this transition by updating responseXML to return a native XML document.
Like IE9, IE10 previews before the Windows 8 Release Preview returned an MSXML document for responseXML. As a result, retrieving a native document required the additional step of passing responseText to DOMParser.
var xhr = new XMLHttpRequest();
//...
var parser = new DOMParser();
var doc = parser.parseFromString(xhr.responseText, 'text/xml');
// 'doc' contains a native document in both IE9 and IE10
In the Windows 8 Release Preview, IE10 eliminates the need for an additional DOMParser step by returning a native document directly via responseXML. Existing code using DOMParser will continue to work in IE10.
var xhr = new XMLHttpRequest();
//...
var doc = xhr.responseXML;
// 'doc' contains a native document in IE10’s Standards and Quirks document modes
// it contains an MSHTML document in IE9 and in IE10’s compatibility document modes
This simplification also applies to the new response property when responseType is set to 'document'.
var xhr = new XMLHttpRequest();
xhr.open(method, url, true);
xhr.responseType = 'document';
//...
var doc = xhr.response;
// 'doc' contains a native document in IE10’s Standards and Quirks document modes
IE10 additionally includes a mechanism to opt-in to retrieving an MSXML document. This can be useful if you still need some MSXML-specific functionality (such as selectNodes) or simply need some extra time to migrate. To do this, set the responseType of your XMLHttpRequest object to 'msxml-document'.
var xhr = new XMLHttpRequest();
xhr.open(method, url, true);
try { xhr.responseType = 'msxml-document'; } catch(e){}
//...
var doc = xhr.responseXML;
// 'doc' now contains an MSXML document in IE10’s Standards and Quirks document modes
In theory the assignment should be ignored by other browsers, but in practice some do throw an exception. You can defend against this using a try/catch statement, as in the above example.
—Tony Ross, Program Manager, Internet Explorer

New Blob Constructor in IE10

IE10 in Windows 8 Release Preview adds support for a Blob constructor. We earlier wrote about and demonstrated IE10’s support for a BlobBuilder interface, an in-progress interface in the File API: Writer W3C Working Draft. This interface enables developers to work with files on the client PC. Recently, the W3C working group deprecated the BlobBuilder interface in favor of a new Blob constructor. This post explains the differences between the two.

Comparing Blob Constructor and BlobBuilder Interface

Both the Blob constructor and the BlobBuilder interface enable Web developers to create files on the client. The difference is in the syntax. Whereas BlobBuilder requires each portion of the blob to be appended during a separate call to the append method, the Blob constructor can take an array of arguments. Here’s how to create a simple text file using both BlobBuilder and the Blob constructor:
// using the Blob constructor
var textBlob1 = new Blob(["Hello", " world!"], { type: "text/plain", endings: "transparent" });

// using the MSBlobBuilder interface
var bb = new MSBlobBuilder();
bb.append("Hello");
bb.append(" world!");
var textBlob2 = bb.getBlob("text/plain");
The Blob constructor takes two arguments, the array of content to put into the blob and an optional dictionary object which can include two members, type and endings. The array of content for the blob may contain blob objects, text strings or array buffers.
Recent versions of Firefox and Chrome also support the Blob constructor. IE10 still supports the prefixed MSBlobBuilder interface in addition to the new Blob constructor. At this time, Firefox and Chrome also support their vendor-prefixed BlobBuilder interface.

Feature Detecting the Blob Constructor

As with all new features, we recommend using feature detection to determine if the Blob constructor is available in the browser your code is running on. You can use something like this:
if (typeof Blob !== "undefined") {
// use the Blob constructor
} else if (window.MSBlobBuilder || window.WebKitBlobBuilder || window.MozBlobBuilder) {
// use the supported vendor-prefixed BlobBuilder
} else {
// neither Blob constructor nor BlobBuilder is supported
}
If you run the BlobBuilder Test Drive demo with the F12 developer tools console window open, it will log whether the blobs are being built via the Blob constructor or via BlobBuilder.
The addition of the Blob constructor to IE10 enables you to write standards-compliant code that works across browsers.
—Sharon Newman, Program Manager, Internet Explorer

воскресенье, 22 июля 2012 г.

IE 9.0.8 Available via Windows Update

The July 2012 Cumulative Security Update for Internet Explorer is now available via Windows Update. This security update resolves two privately reported vulnerabilities in Internet Explorer. The vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. An attacker who successfully exploited any of these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. This security update is rated Critical for Internet Explorer 9 on Windows clients and Moderate for Internet Explorer 9 on Windows servers. For more information, see the full bulletin.
Most customers have enabled automatic updating and do not need to take any action. We recommend that customers, who have not enabled automatic updating, enable it (Start Menu, type “Windows Update”). We recommend that administrators, enterprise installations, and end users who want to install this security update manually, apply the update immediately using update management software or by checking for updates using the Microsoft Update service.
—Tyson Storey, Program Manager, Internet Explorer

IE10 User Agent String Update

The IE10 user agent string was originally introduced in the first platform preview of IE10. In Windows 8 Release Preview we made two additions to aid server-side feature detection.
The first addition enables detecting whether a machine has touch-capable hardware via a new Touch token. Using this token you can present a touch-friendly version of your site to users with touch-capable hardware (typically, in the case where your normal site is not touch-friendly). Keep in mind that users with touch-capable hardware may also use a mouse and keyboard. You can see where this token fits into the user agent string in the examples below.
  • IE10 on a machine without touch-capable hardware:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
  • IE10 on a machine with touch-capable hardware:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; Touch)
If you're detecting touch support client-side, do not sniff the user agent string; use navigator.msMaxTouchPoints instead. If the property exists and returns a value greater than zero, the user’s PC has touch capability. For example:
var hasTouch = navigator.msMaxTouchPoints > 0;
The second addition to the IE10 user agent string is a new architecture token for ARM devices running Windows RT. This complements the existing values for other architectures. The examples below show how this compares to a few other configurations.
  • 32-bit IE10 on 32-bit Windows:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
  • 32-bit IE10 on 64-bit Windows:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
  • 64-bit IE10 on 64-bit Windows:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64; Trident/6.0)
  • IE10 on Windows RT:
    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; ARM; Trident/6.0)
These additions apply to both desktop and Metro style IE10 since they expose the same platform capabilities. We recommend optimizing your site’s experience around the capabilities of the system (like Touch) through feature detection, rather than browser or environment detection. Where content depends on plug-ins, use the requiresActiveX prompt to help users switch to desktop IE10 until the content can be made plug-in free.
—Tony Ross, Program Manager, Internet Explorer

XMLHttpRequest responseXML in IE10 Release Preview

IE10 in Windows 8 Release Preview updates the responseXML from an XMLHttpRequest to return a native XML document by default. This change applies to IE10’s Standards and Quirks document modes, making them interoperable with other modern browsers and consistent with a “same markup” approach. Compatibility document modes 5, 7, 8, and 9 are unchanged.
This change may impact sites that were expecting responseXML to contain an MSXML document and depended on MSXML-specific functionality such as selectNodes. In these cases, you may request that IE10 return an MSXML by setting the responseType member of your XMLHttpRequest object to 'msxml-document'. If your code does not depend on MSXML-specific functionality, IE10’s native XML document should work for you.
Native XML support in IE9 brought DOM parity to XML and HTML and enabled XML fragments to be inserted and rendered directly within a page (even in HTML). IE9 also simplified converting between XML and DOM with the addition of DOMParser and XMLSerializer. IE10 completes this transition by updating responseXML to return a native XML document.
Like IE9, IE10 previews before the Windows 8 Release Preview returned an MSXML document for responseXML. As a result, retrieving a native document required the additional step of passing responseText to DOMParser.
var xhr = new XMLHttpRequest();
//...
var parser = new DOMParser();
var doc = parser.parseFromString(xhr.responseText, 'text/xml');
// 'doc' contains a native document in both IE9 and IE10
In the Windows 8 Release Preview, IE10 eliminates the need for an additional DOMParser step by returning a native document directly via responseXML. Existing code using DOMParser will continue to work in IE10.
var xhr = new XMLHttpRequest();
//...
var doc = xhr.responseXML;
// 'doc' contains a native document in IE10’s Standards and Quirks document modes
// it contains an MSHTML document in IE9 and in IE10’s compatibility document modes
This simplification also applies to the new response property when responseType is set to 'document'.
var xhr = new XMLHttpRequest();
xhr.open(method, url, true);
xhr.responseType = 'document';
//...
var doc = xhr.response;
// 'doc' contains a native document in IE10’s Standards and Quirks document modes
IE10 additionally includes a mechanism to opt-in to retrieving an MSXML document. This can be useful if you still need some MSXML-specific functionality (such as selectNodes) or simply need some extra time to migrate. To do this, set the responseType of your XMLHttpRequest object to 'msxml-document'.
var xhr = new XMLHttpRequest();
xhr.open(method, url, true);
try { xhr.responseType = 'msxml-document'; } catch(e){}
//...
var doc = xhr.responseXML;
// 'doc' now contains an MSXML document in IE10’s Standards and Quirks document modes
In theory the assignment should be ignored by other browsers, but in practice some do throw an exception. You can defend against this using a try/catch statement, as in the above example.
—Tony Ross, Program Manager, Internet Explorer

New Blob Constructor in IE10

IE10 in Windows 8 Release Preview adds support for a Blob constructor. We earlier wrote about and demonstrated IE10’s support for a BlobBuilder interface, an in-progress interface in the File API: Writer W3C Working Draft. This interface enables developers to work with files on the client PC. Recently, the W3C working group deprecated the BlobBuilder interface in favor of a new Blob constructor. This post explains the differences between the two.

Comparing Blob Constructor and BlobBuilder Interface

Both the Blob constructor and the BlobBuilder interface enable Web developers to create files on the client. The difference is in the syntax. Whereas BlobBuilder requires each portion of the blob to be appended during a separate call to the append method, the Blob constructor can take an array of arguments. Here’s how to create a simple text file using both BlobBuilder and the Blob constructor:
// using the Blob constructor
var textBlob1 = new Blob(["Hello", " world!"], { type: "text/plain", endings: "transparent" });

// using the MSBlobBuilder interface
var bb = new MSBlobBuilder();
bb.append("Hello");
bb.append(" world!");
var textBlob2 = bb.getBlob("text/plain");
The Blob constructor takes two arguments, the array of content to put into the blob and an optional dictionary object which can include two members, type and endings. The array of content for the blob may contain blob objects, text strings or array buffers.
Recent versions of Firefox and Chrome also support the Blob constructor. IE10 still supports the prefixed MSBlobBuilder interface in addition to the new Blob constructor. At this time, Firefox and Chrome also support their vendor-prefixed BlobBuilder interface.

Feature Detecting the Blob Constructor

As with all new features, we recommend using feature detection to determine if the Blob constructor is available in the browser your code is running on. You can use something like this:
if (typeof Blob !== "undefined") {
// use the Blob constructor
} else if (window.MSBlobBuilder || window.WebKitBlobBuilder || window.MozBlobBuilder) {
// use the supported vendor-prefixed BlobBuilder
} else {
// neither Blob constructor nor BlobBuilder is supported
}
If you run the BlobBuilder Test Drive demo with the F12 developer tools console window open, it will log whether the blobs are being built via the Blob constructor or via BlobBuilder.
The addition of the Blob constructor to IE10 enables you to write standards-compliant code that works across browsers.
—Sharon Newman, Program Manager, Internet Explorer

воскресенье, 8 июля 2012 г.

Adapting Your Site to Different Window Sizes

IE10 in the Windows 8 Release Preview supports the width and height properties of the W3C Working Draft CSS Device Adaptation. This gives Web developers a simple tool to control automatic content scaling across various window dimensions. In particular, it enables Web sites to easily adapt to Windows 8 Metro style browser in the snapped view and portrait orientation.

Auto-Scaling and When It Is Used

Most websites have prioritized optimization for a 1024 pixel wide window. This ensures a good user experience for a wide variety of displays when the browser is maximized. However, sites may not work well on new form factors like tablets and portrait screen orientation if they haven't optimized for other window sizes as well. In particular, pages often clip or distort layout when viewed in a narrow width.
Screen shot of TechCrunch Web site displayed in a very narrow Window. Only the left edge of the site content is visible.Screen shot of a Wikipedia displayed in a very narrow Window. The left navigation bar is visible; the featured article is readable but wrapped in a very narrow column.
TechCrunch and Wikipedia displayed in very narrow windows
This narrow layout is particularly important in Windows 8, where the snapped view of the Metro style browser is in this exact state. This situation also occurs for portrait mode on slate devices due to the smaller form factor.
In the Metro style browser, the snapped view and portrait mode are auto-scaled by default to ensure at least 1024 pixels of layout width. Mobile devices take a similar approach when displaying non-mobile-optimized sites on a narrow form factor. Since most sites are built to work well at 1024 pixels, this ensures that they are laid out well and do not clip content by default.
Screen shot of TechCrunch Web site displayed in Metro style snapped view. The whole page as laid out to a 1024 pixel width is visible and zoomed down to fit.Screen shot of Wikipedia displayed in Metro style browser in snapped view. The whole page as laid out to a 1024 pixel width is visible and zoomed down to fit.
TechCrunch and Wikipedia displayed in Windows 8 Metro style browser in snapped view
Although this approach ensures a good default experience, users will need to zoom in to view and interact with the site.

Working Well In a Narrow Window

The best narrow layouts are those that have been custom-made by the Web developer. In addition to fitting the site into a narrower region, this also may require changes to image sizes, reordering of content, alternative tools for site navigation, or other fundamental changes to content.
If your site has already made these modifications for narrow windows, then Device Adaptation can be used to override the default scale.
For some great examples of adaptive layouts, check out Media Queries. Metal Toad Media also has a great article discussing layout width support based on prevalent devices and screen sizes in the market.

Using @-ms-viewport

Simple support for the snapped view. If your site is already capable of a 320 pixel width layout, you can easily choose to show that version in the snapped view. Combining Device Adaptation with CSS media queries allows the auto-scaling feature to be overridden selectively. This CSS overrides the default auto-scaling, and instead enforces a consistent 320 pixel layout width for all windows 320 pixels wide or narrower:
@media screen and (max-width: 320px) {
@-ms-viewport { width: 320px; }
}
When the window is less than 320 pixels wide the content will be scaled down to fit. For example, a 300 pixel wide window will show the content at 93.75% scale. For larger widths, IE10’s normal scaling applies (for example, when the Metro style browser is in portrait mode).
Device adaptation degrades gracefully in browsers which do not yet support it. These browsers can still benefit from narrow layout support—they just won’t auto-scale to fit content to the window.
Portrait support. If your site supports a 768 pixel wide layout as well, then portrait mode support can be easily added with a second viewport rule:
@media screen and (max-width: 320px) {
@-ms-viewport { width: 320px; }
}
 
@media screen and (min-width: 768px) and (max-width: 959px) {
@-ms-viewport { width: 768px; }
}
We recommend testing your site in layout widths of 768 pixels (portrait on most slates) and 320 pixels (snapped Metro style browser) in addition to 1024 pixels and wider (landscape). You can see an example of the viewport rule in action in the Make it Snappy! demo on the IE Test Drive site.
—Matt Rakow, Program Manager, Internet Explorer

Go Beyond Pan, Zoom, and Tap Using Gesture Events

Based on your feedback, we’ve improved how sites can build advanced touch experiences using gesture events in IE10 on the Windows 8 Release Preview. Earlier we wrote about first steps Web developers should take to make sure their sites are touch-friendly and how to build new experiences that work well across input devices, including multi-touch, using hardware agnostic pointer events. This post covers IE10’s gesture events. An example of gesture events is the Browser Surface Test Drive demo shown below.
Screen shot of the Browser Surface demo showing pictures randomly arranged on the surface.
Users can drag, pinch, and rotate photos using the Browser Surface demo
IE10 in the Windows 8 Release Preview introduces gesture recognition objects in JavaScript. Sites can create gesture objects, decide which pointers (mouse, pen, or touch contacts) to process, and direct the gesture events at whatever element is desired. The browser then calculates what gesture is being performed and notifies the page via events. This enables developers to build gesture experiences not yet natively possible in any other browser. These include multiple concurrent gestures, for example, rotating two puzzle pieces with your hands.
Let’s take a look at how this works in code.

Creating a Gesture Object

The first step in handling gestures in your site is to instantiate a gesture object.
var myGesture = new MSGesture();
Next, give the gesture a target element. This is the element to which the browser will fire gesture events. It’s also the element that determines the coordinate space for the events.
elm = document.getElementById("someElement");
myGesture.target = elm;
elm.addEventListener("MSGestureChange", handleGesture);
Finally, tell the gesture object which pointers to process in its gesture recognition.
elm.addEventListener("MSPointerDown", function (evt) {
// adds the current mouse, pen, or touch contact for gesture recognition
myGesture.addPointer(evt.pointerId);
});
Note: don’t forget you need to use –ms-touch-action to configure the element to not perform default touch actions like panning and zooming, and instead provide pointer events for the input.

Handling Gesture Events

Once a gesture object has a valid target and at least one pointer added to it, it will begin to fire gesture events. The gesture events come in 2 flavors: static gestures (like tap or hold) and dynamic gestures (like pinch, rotate, or swipe).

Tap

The most basic gesture recognition is a Tap. When a tap is detected, the MSGestureTap event is fired at the target element of the gesture object. Different from the click event, the tap gesture only fires when a user touches (or presses a mouse button, or touches a pen) down and up without moving. This is often useful if you want to differentiate between a user tapping on an element versus dragging the element.

Press and Hold

A press and hold gesture happens when a user touches down with one finger, holds for a moment, and lifts without moving. During a press & hold interaction, the MSGestureHold event fires more than once for the various states of the gesture:
element.addEventListener("MSGestureHold", handleHold);
function handleHold(evt) {
if (evt.detail & evt.MSGESTURE_FLAG_BEGIN) {
// Begin signals the start of a gesture. For the Hold gesture, this means the user has been holding long enough in place that the gesture will become a complete press & hold if the finger is lifted.
}
if (evt.detail & evt.MSGESTURE_FLAG_END) {
// End signals the end of the gesture.
}
if (evt.detail & evt.MSGESTURE_FLAG_CANCEL) {
// Cancel signals the user started the gesture but cancelled it. For hold, this occurs when the user drags away before lifting. This flag is sent together with the End flag, signaling the gesture recognition is complete.
}
}

Dynamic Gestures (pinch, rotate, swipe, and drag)

Dynamic gestures, like pinch or rotate, are reported in the form of transforms similar to CSS 2D Transforms. Three events are fired for dynamic gestures: MSGestureStart, MSGestureChange (fires repeatedly as the gesture continues), and MSGestureEnd. Each event contains information about scale (pinch), rotation, translation, and velocity.
Because dynamic gestures report transforms, it’s easy to use MSGesture with CSS 2D Transforms to manipulate an element like a photo or puzzle piece. For example, you can enable scaling, rotating, and dragging of element as follows:
targetElement.addEventListener("MSGestureChange", manipulateElement);
function manipulateElement(e) {
// Uncomment the following code if you want to disable the built-in inertia provided by dynamic gesture recognition
// if (e.detail == e.MSGESTURE_FLAG_INERTIA)
// return;
 
var m = new MSCSSMatrix(e.target.style.transform); // Get the latest CSS transform on the element
e.target.style.transform = m
.translate(e.offsetX, e.offsetY) // Move the transform origin under the center of the gesture
.rotate(e.rotation * 180 / Math.PI) // Apply Rotation
.scale(e.scale) // Apply Scale
.translate(e.translationX, e.translationY) // Apply Translation
.translate(-e.offsetX, -e.offsetY); // Move the transform origin back
}
Dynamic gestures like scale and rotate are supported with mouse by rotating the mouse wheel with the CTRL or SHIFT modifier keys, respectively.

Summary

IE10’s gesture events enable you to build touch experiences not currently possible in any other browser. See MSDN for in-depth documentation of MSGesture objects and MSGesture events.
Take your sites beyond pan, zoom, and tap using gesture events.
—Jacob Rossi, Program Manager, Internet Explorer

Developer Guidance for Web Sites with Flash Content in Windows 8

The Windows 8 Release Preview includes a new power-optimized, touch-friendly Adobe Flash Player. Adobe Flash content on compatible Web sites will now play in Metro style IE10. Metro style IE10 with Flash on Windows 8 enables people to see more of the Web working with high quality, especially compared with the experience in other touch-first or tablet experiences.
On Windows 8, Internet Explorer 10 on the desktop and Metro style IE use the same integrated Adobe Flash Player with no need to download or install an additional player. IE10 on the desktop provides the same full Flash support as previous versions of IE that relied on the Flash Player plug-in from Adobe and continues to support other 3rd party plug-ins. Metro style IE continues to provide no support for 3rd party ActiveX controls or plug-ins.
While any site can play Flash content in IE10 on the Windows desktop, only sites that are listed in the Flash section of the Compatibility View (CV) list can play Flash content within Metro style IE. (Being listed in the Flash section does not affect a site’s document mode.) We place sites with Flash content on this list if doing so delivers the best user experience in Metro style IE with those sites. For example, how responsive is the content to touch? Does it work well with the onscreen keyboard? Is it battery-life friendly? Do visual prompts comply with the Metro style user experience guidelines? Sites that rely on capabilities that are not supported within the Metro style experience, for example, Flash rollover events and P2P functionality, and don’t degrade gracefully in their absence are better off running in IE with Flash on the desktop.
Site developers continue to control the content they serve to browsers. Developers can send HTML5 content to Metro style IE or express their preference that Metro style IE prompt users to run their site on the desktop (see details here). Developers can also request that their site is considered for addition to the CV list for Flash. Additional technical information and details can be found in the document posted on MSDN. These details include how developers can test Flash content on their own sites in Metro style IE and how to submit their sites for consideration for the CV list. The documentation also includes a best practices guide to help developers, designers, and content publishers create experiences with Flash that play well in Metro style IE.
—Rob Mauceri, Group Program Manager, Internet Explorer

Unprefixed CSS3 Gradients in IE10

IE10 in the Windows 8 Release Preview supports the W3C Candidate Recommendation for CSS Gradients in their unprefixed form. IE10 also supports the older CSS Gradients syntax from the W3C Working Draft of 17 February 2011 behind the vendor prefix -ms-. This blog post describes the differences between the old and new syntax and behavior and provides some insight into the change.

Key Changes

Should you choose to simplify your CSS by making the move from vendor-prefixed CSS3 Gradients to unprefixed CSS3 Gradients, there are some key syntax changes to be aware of. Many gradient generators have provided cross-browser markup, including markup for unprefixed gradients. In many cases, the unprefixed markup is no longer valid according to the CSS Image Values W3C Candidate Recommendation that covers gradients. Here are the changes you should be aware of.

Linear and Repeating Linear Gradients

Working Draft Candidate Recommendation
Direction Keywords The top, bottom, left, and right keywords describe the gradient line’s direction via its starting point. The preposition “to” precedes the keywords top, bottom, left, and right keywords describe the gradient line’s direction via its ending point.
Example -ms-linear-gradient(top, orange, black); linear-gradient(to bottom, orange, black);
An example linear gradient going from orange on top to black on the bottom. An example linear gradient going from orange on top to black on the bottom.
Corner calculation Corner keywords specify a gradient line drawn from that corner to the opposite corner. Corner keywords are preceded by “to” and specify a gradient line beginning from the quadrant specified and ending in the opposite quadrant. The center point of the gradient line intersects a line drawn between the remaining two corners.
Example -ms-linear-gradient(top left, fuchsia, yellow); linear-gradient(to bottom right, fuchsia, yellow);
Diagram showing how the angle associated with a corner-to-corner gradient was computed in the old working draft.
Diagram showing how the angle associated with a corner-to-corner gradient is computed in the new candidate recommendation.
Angle Direction 0deg is a gradient line pointing to the right. Angles increase in a counterclockwise direction. 0deg is a gradient line pointing to the top. Angles increase in a clockwise direction. Old angles can be converted to new angles using the formula new = abs(old−450) mod 360
Diagram showing angles in the old working draft with zero degrees at the 3:00 location and positive degrees going counterclockwise. Diagram showing angles in the new candidate recommendation with zero degrees at the 12:00 location and positive degrees going clockwise.
Example -ms-linear-gradient(200deg, lime, magenta); linear-gradient(250deg, lime, magenta);
Example of an angled gradient with magenta in the lower left and lime in the upper right. Example of an angled gradient with magenta in the lower left and lime in the upper right.

Radial Gradients and Repeating Radial Gradients

Working Draft Candidate Recommendation
Position Position keywords or lengths describe the location of the center of the gradient. Position keywords or lengths are preceded by the preposition “at” to describe the location of the center of the gradient. The position is now specified after gradient shape and size, if present.
Example -ms-radial-gradient(center, aqua, black); radial-gradient(at center, aqua, black);
Example of a radial gradient with aqua in the center and black in the corners. Example of a radial gradient with aqua in the center and black in the corners.
Size Keywords Gradient size is defined by one of the six keywords: farthest-corner, farthest-side, closest-corner, closest-side, contain, and cover. Gradient size is defined by one of the four keywords: farthest-corner, farthest-side, closest-corner, and closest-side. contain and cover are no longer valid and correspond to closest-side and farthest-corner, respectively.
Example -ms-radial-gradient(circle cover, lime, black); radial-gradient(circle farthest-corner, lime, black);
Example of a circular radial gradient with lime in the center and black in the corners sized so that the circle diameter matches the longer dimension. Example of a circular radial gradient with lime in the center and black in the corners sized so that the circle diameter matches the longer dimension.
Size and Shape Syntax Radial gradients specified with lengths must have both the horizontal and vertical radius lengths specified. Radial gradients may be specified with only a single radius length for circles.
Example -ms-radial-gradient(center, 50px 50px, red, black); radial-gradient(circle 50px at center, red, black);
Example of a 50px circular radial gradient with red in the center fading to black at the edge of the circle. The circle is centered in the containing rectangle. Example of a 50px circular radial gradient with red in the center fading to black at the edge of the circle. The circle is centered in the containing rectangle.

Background

CSS3 Gradients are defined within the CSS Image Values and Replaced Content Module Level 3 W3C Candidate Recommendation. Gradients were first added to the specification in 2009. They were based on the gradients introduced in WebKit, but with improvements to the syntax. At that time, WebKit had an implementation for -webkit-gradient(). The CSS Working Group iterated on the feature and altered its syntax. Radial gradients and linear gradients would be specified with separate property values, linear-gradient() and radial-gradient(). Fast forward a couple years and all major browsers—Chrome, Firefox, IE10 Platform Preview 1, and Opera—had introduced support for the version of CSS gradients described in the W3C Working Draft of 17 February 2011.
When the Working Draft was closely scrutinized, several changed were suggested and after much discussion the specification was edited to reflect these changes. The major changes, listed in the table above, improved the old specification by addressing issues of clarity and consistency. For instance, in the old angle coordinate system, positive angles increased in a counterclockwise manner. This is in contrast to CSS Transforms and SVG Transforms, where positive angle rotations occur in a clockwise manner. With the specification change, angles that describe CSS gradients are now consistent across other CSS angles and increase in a clockwise manner.
In the process of changing gradients’ syntax, compatibility was a recognized concern despite the specification being in a Working Draft stage. Not all cases are compatible, but much existing content will continue to work. Default values remain the same, so their rendering will be unchanged. For gradient-line direction, the required “to” preposition both adds clarity and changes the valid grammar. Existing content with unprefixed gradients using the old syntax will be invalid, thereby falling back on the vendor-prefixed version.

Update Your Unprefixed Gradients

Now that CSS3 Gradients are stable, we encourage you to update your gradients markup to the correct Candidate Recommendation unprefixed gradient syntax. The Internet Explorer 10 Guide for Developers includes full updated documentation of the unprefixed syntax. You may also remove instances of the -ms- prefixed gradients, as IE10 supports the unprefixed version. If you’re using corner keywords or angles to describe gradient direction, you may want to verify that your gradients still render as desired.
While vendor-prefixed gradients still work in IE10 and other browsers, adding correct support for unprefixed gradients future-proofs your content.
—Jennifer Yu, Program Manager, Internet Explorer

Test the Web Forward

The quality and correctness of different browsers’ HTML5 engines continue to vary widely. We continue to contribute to the test suites under development at W3C to further the goal of web platform interoperability and same markup. In total, we have submitted 7573 tests that you can view at the IE Test Center as well. As different browsers improve their same-markup support, we can all realize the promise of HTML5.
The title of this post refers to the week-end event hosted by Adobe on June 15 and 16 at their San Francisco office. Dozens of volunteers joined W3C experts and members from Adobe, Google, Mozilla, Apple, HP, and Microsoft to learn about Web standards testing, how to write CSS and SVG tests, how to file good bugs, as well as the tools available for test suite management.
The meeting then turned into a test ‘hack-a-thon’ fueled by free drinks and food throughout the day. Volunteers spent most of their Saturday writing new test cases for the CSS OM, Transforms, Backgrounds & Borders, Exclusions, SVG, and other modules. Participants were then nominated for several prizes.

Testing Web Standards

Adobe’s Alan Stearns introduced the participants to the general principles of W3C testing and the role of testing in moving specifications forward. In particular, establishing browsers’ individual pass rate for a given specification is not a goal of W3C test suites. In order for a specification to become a W3C Recommendation the Working Group must prove it can be implemented. In practice this means:
  • Creating a test case for each requirement in the specification (these are known as normative statements)
  • Verifying that at least two separate implementations pass each test
Note the difference between ‘at least two browsers must pass the entire test suite’ and ‘at least two browsers must pass each test in the test suite’. Browser testers usually describe this phase as ‘testing the spec’.
But an important side-effect of this testing process is to establish a common interoperable baseline that all browsers can develop and test against. Test suites help find bugs across all browsers and can sometimes identify issues in the spec.

Writing CSS and SVG Tests

There are three different types of tests:
  • Stand-alone tests typically rely on visual verification: if a failure condition occurs, red content will show.
  • Reference tests compare a test against a visual reference that has no dependency on the feature being tested. Note that the test includes a link to the reference test against which is should be compared.
  • CSS Object Model tests depend on a JavaScript test harness; they verify that the object model reflects what static style sheets specify. For instance, this CSS media query test.
W3C’s Doug Schepers covered SVG testing while Adobe’s Rebecca Hauck and Jacob Goldstein provided a test writing tutorial. Peter Linss, CSS Working Group co-chair, offered a deep dive on the CSS testing framework including the test suite build system and management tools such as Shepherd.

Filing Good Bugs

Mozilla’s Elika Etemad then gave attendees advice on what makes a good browser bug report:
  • The issue is specific and reproducible
  • The build and platform are identified
  • You have looked for duplicates
  • It includes steps to reproduce the problem
  • The expected and actual results are described
  • If possible, the issue has been reduced i.e. all HTML, JavaScript and CSS that is not necessary to reproduce the problem has been eliminated from the problem page and the remainder attached to the bug.

Building a Test Suite

Building a test suite is a significant investment. One of the reasons it took a long time for CSS2.1 to reach the Recommendation stage was the size of the specification and the underlying number of requirements to test. The latest version of the test suite contains 9,422 tests.
Microsoft contributed over 7,000 of those tests, and we are continually contributing more tests for other standard specifications.
In IE10, we have added support for a long list of new standard features across CSS, HTML, SVG and the DOM. We have published some of our testcases for these new features on our IE Test Center. We will be submitting more, notably around those features recently unprefixed in the IE10 Release Preview.

How You Can Help

We are excited to be part of the community working towards a more interoperable web. If you want to help move the Web forward, you too can help to drive interoperability higher. You can learn how to contribute tests, or review existing tests. More information for those is available on the CSS WG wiki as well as on the event page.
We will keep you posted on future events.
—Sylvain Galineau, Program Manager, Internet Explorer and
John Jansen, Test Lead, Internet Explorer