The ES5 standard became official in December 2009 and the third IE9 Platform Preview is the first widely distributed implementation of some subtle details of the ES5 specification. ES5 was designed to be highly compatible with existing websites and the Ecma International TC39 technical committee worked to avoid any non-security related changes that might break existing JavaScript code. However, perfection generally does not exist in the world of software so with the third IE9 Platform Preview we were very interested to see if any ES5-related compatibility problems with existing sites would show up.

Soon after releasing this platform preview, we received reports that some web-apps that use the jQuery framework did not work correctly in the preview. We tracked the problem to a specific jQuery API method that in some cases passed a caller provided value to Object.prototype.toString without first checking if the value was null or undefined. Specifically, some calls to this jQuery method:

isFunction: function( obj ) {
     return toString.call(obj) === "[object Function]";
},

failed with an exception: “TypeError: Object expected”. Further analysis showed that toString in the above code was the built-in method Object.prototpe.toString and that the failures occurred when isFunction was being called with undefined as its argument. Why does an exception occur in IE9 and not in previous versions of IE or other browsers? It is because the third IE9 Platform Preview in standards mode actually conforms to the ES5 specification for Object.prototype.toString.

According to the prior editions of the ECMAScript specification, calling any built-in method using null or undefined as the this value passes the “global object” (in browsers this is the DOM window object) to the method as its this value.  This opens a number of potential security holes for frameworks that aim to support mash-ups in a secure way.

The ES5 specification changed this so that null or undefined is not replaced with the window object and the definition for each built-in method was updated specifically to deal with receiving these values as their this value. The ECMAScript technical committee tried to do this in a way that preserves backwards compatibility for normal usage and throws an exception in cases where that is not possible. Object.prototype.toString was specified in ES5 to throw such an exception. This created the compatibility problem described above.

This problem can be easily corrected by modifying the jQuery code with the additions shown in red:

isFunction: function( obj ) {
     return obj && toString.call(obj) === "[object Function]";
},

The jQuery team actually intends to make this change. However, such a change will not correct the thousands of locally hosted copies of jQuery that already exist on the Web. With the broad use of jQuery, it is clear that the ES5 specification contains a significant compatibility problem. It is fairly obvious how we can modify the IE9 ES5 implementation to eliminate the problem. We can just return the same string value ("[object Object]") that IE8 returns in this situation. Such a fix does not reintroduce any of the security problems that ES5 strives to eliminate. However, we do not want to unilaterally introduce such a variation into our implementation of a new standard. It does not help either compatibility or interoperability if IE fixes this problem one way, and other browsers either don’t fix it or fixed it a different way.

As soon as we understood the problem and the possible solution, I raised this on the TC39 es5-discuss mailing list as a backwards compatibility issue.  My first post on the issue went out at 5:51 PM on June 25, a Friday. By 10 PM there were responses from TC39 members representing Apple, Mozilla, and Google. We all agreed that this was a compatibility issue that needed to be fixed, and that in this case throwing the exception was unnecessary and undesirable. We also initially agreed that the idea of returning the same string value as ES3 for these cases sounded like a good idea. However, in further messages over the weekend we realized that browsers currently don’t all return "[object Object]" in this situation, some other values that were observed include "[object Window]" and "[object Global]". A proposal was made to return "[object null]" and "[object undefined]". This seemed to be a better solution as it not only fixes use cases such as jQuery’s but it also explicitly distinguishes null and undefined from actual objects. It is also better for browser interoperability because it requires that all browsers produce identical results rather than the ES3 situation that allowed different browsers to produce different results.

By Tuesday, the consensus on the mailing list was to follow this final proposal. As soon as that agreement was reached, I passed the revised Object.prototype.toString specification on to our IE9 JavaScript development team so they could make the fix in time to widely test it with the next IE9 platform preview build.  Mozilla has also indicated that they will be incorporating this fix into a future Firefox beta. I also updated the official TC39 Erratum for ES5  so this specification change is recorded there (section 15.2.4.2).

Web standards are complex software artifacts and like all software, they contain bugs. Sometimes the best way to find and fix compatibility bugs is to implement and deploy the standard on widely used browsers. This generally takes place in the context of early releases such as the IE9 platform preview builds. So, when you as a web developer are providing feedback on such releases you aren’t just providing feedback on a specific browser you are also providing feedback on the new and emerging standards that it implements. Of course, for this feedback to be worthwhile, browser implementers and standards authors need to be able and willing to quickly respond to feedback that identifies significant problems. The rapid response to the ES5 jQuery toString problem and other issues on es5-discuss show how browser implementers and other TC39 members can and do work closely together to create a more compatible and interoperable Web. But it all starts with your feedback, so please keep it coming.

Allen Wirfs-Brock
Microsoft JavaScript Language Architect

“Web design is 95% typography”. So much of the content produced and consumed on the web is text yet designers and users have been confined to a set of compatible fonts available across client operating systems. Escaping this typographical island has involved everything from cross-browser CSS workarounds, graphics-based solutions and even plug-ins, with trade-offs ranging from extra storage and bandwidth to reduced accessibility.

As a result, typefaces have too often been one of the first casualties of the translation from Photoshop design mock-up to live web page.

Not The Same CSS

Solving this challenge required an interoperable CSS syntax to describe font resources. While IE added support for CSS2’s @font-face rule as long ago as 1997, the differences between this earliest of implementations and the far more recent ones supporting CSS3 Fonts have given rise to CSS design patterns built to ensure the same rule works for all users. A notable example is the bulletproof @font-face syntax developed by Paul Irish from Google, et al.

But crafting a cross-browser @font-face declaration turned out to be half the problem.

No Common Web Font Format

Internet Explorer’s @font-face implementation supports EOT (Embedded OpenType) fonts, a compressed font encoding submitted to the W3C in 2008. Following WebKit’s lead in 2007, Mozilla and Opera added support for raw TrueType and OpenType fonts. Raw fonts work well if your fonts’ end-user license (EULA) allowed you to serve them from your web server. While this is true for many free fonts, this is not the case for the vast majority of commercial fonts. Web authors are thus effectively cut off from the richest font catalogs available. If they choose EOT they are able to license a number of commercial fonts for web use but only IE renders them.

This leaves a challenge for the industry. The major browsers support two incompatible solutions and commercial font EULAs are generally incompatible with one of them.  This spawned dedicated hosting services like TypeKit to help designers license typefaces for their site and use them across browsers. These services, however, may not offer all or even any of the desired fonts that a web developer needs for their site. In some cases, a font set could even require multiple subscriptions.

WOFF

In late 2009, type designers Tal Leming and Erik van Blokland working together with Mozilla’s Jonathan Kew proposed a new web font container format to address the concerns of font vendors without reducing web author choice. It was well received and submitted to the W3C in April 2010 by Mozilla, Opera and Microsoft. Today, Firefox 3.6 supports WOFF and other browser vendors will be following soon.

Font foundries have also rallied behind the new format and already offer WOFF-encoded fonts for web use. Among them, Monotype Imaging, Ascender Corporation, FontShop and Typotheque provided us with the great WOFF fonts used in our our Testdrive demos.

Same CSS, Same Web Font Format

Starting with Platform Preview 3, IE9’s @font-face implementation conforms to the CSS3 Fonts module; supported font formats include EOT and WOFF as well as raw fonts with embedding permissions set to installable.

In future posts, we will look into IE9’s web font support in more detail, as well as the available techniques for cross-browser typography. In his latest post on the FontBlog, Greg Hitchcock offers rich context on the art and science behind the technologies involved in web typography.

We look forward to your feedback on this Preview release, as well as ongoing work within the W3C to extend the reach of the typographic web.

Sylvain Galineau
Program Manager

We’ve made a tremendous number of improvements to the way that Internet Explorer 9 caches content to ensure that as many resources as possible are loaded from the cache. This post describes those improvements which are now available in the third IE9 Platform Preview which was released last month.

Understanding Caching

Let’s start with a quick refresher on how caching works in browsers. At a high level, web browsers make two types of requests over HTTP and HTTPS—conditional requests and unconditional requests.

An unconditional request is made when the client browser does not have a cached copy of the resource available locally. In this case, the server is expected to return the resource with a HTTP/200 OK response. If the response’s headers permit it, the client may cache this response in order to reuse it later.

If the browser later needs a resource which is in the local cache, that resource’s headers are checked to determine if the cached copy is still fresh. If the cached copy is fresh, then no network request is made and the client simply reuses the resource from the cache.

If a cached response is stale (older than its max-age or past the Expires date), then the client will make a conditional request to the server to determine whether the previously cached response is still valid and should be reused. The conditional request contains an If-Modified-Since and/or If-None-Match header that indicates to the server what version of the content the browser cache already contains. The server can indicate that the client’s version is still fresh by returning HTTP/304 Not Modified headers with no body, or it can indicate that the client’s version is obsolete by returning a HTTP/200 OK response with the new version of the content.

Obviously, conditional requests result in better performance than unconditional requests (because the server need not retransmit the entire file if the client’s version is fresh) but the best performance is obtained when the client knows that the version in its cache is fresh and the conditional revalidation can be avoided entirely.

Extremely Long-Life Cache Headers

While RFC2616 recommends that servers limit freshness to one year, some servers send Cache-Control directives specifying a much longer freshness lifetime. Prior to IE9, Internet Explorer would treat as stale any resource with a Cache-Control: max-age value over 2147483648 (2^31) seconds, approximately 68 years.

With Internet Explorer 9, we now accept any value up to 2^63 for the max-age value, although internally the freshness interval will be truncated to 2^31 seconds.

Vary Improvements

The HTTP/1.1 Vary response header allows a server to specify that a fresh cached resource is valid for future reuse without server revalidation only if the specified request headers in the later request match the request headers in the original request.

For example, this enables a server to return content in English with a Vary: Accept-Language header. If the user later changes their browser’s Accept-Language from en-US to ja-JP, the previously cached content will not be reused, because the Accept-Language request header no longer matches the request header at the time that the original English response was cached.

With Internet Explorer 9, we’ve enhanced support for key Vary header scenarios. Specifically, IE9 will no longer require server revalidation for responses which contain Vary: Accept-Encoding and Vary: Host directives.

We can safely support these two directives because:

1. All requests implicitly vary by Host, because the host is a component of the request URL.
2. IE always decompresses HTTP responses in the cache, making Vary: Accept-Encoding redundant.

Like IE6 and above, IE9 will also ignore the Vary: User-Agent directive.

If a response contains a Vary directive that specifies a header other than Accept-Encoding, Host, or User-Agent (or any combination of these) then Internet Explorer will still cache the response if the response contains an ETAG header. However, that response will be treated as stale and a conditional HTTP request will be made before reuse to determine if the cached copy is valid.

Redirect Caching

Internet Explorer 9 now supports caching of HTTP redirect responses, as described by RFC 2616. Responses with Permanent Redirect status (301) are cacheable unless there are headers which forbid it (e.g. Cache-Control: no-cache) and those with Temporary Redirect status (302 or 307) are cacheable if there are headers which permit it (e.g. Cache-Control: max-age=120).

While this significantly improves performance, web applications that are misconfigured might not work as expected after this change. For example, we’ve found a few commonly-visited sites that use a pattern which looks like this:

> GET / HTTP/1.1 
< 301 Redirect to /SetCookie.asp

> GET /SetCookie.asp HTTP/1.1 
< 301 Redirect to /

The site’s goal is to have the homepage determine if the user has a cookie set, and if not, send them to a page that sets the cookie. The problem is that the server has chosen a 301 for this task, and a 301 is cacheable. Hence, IE will simply redirect between these two cached redirects on the client (never again contacting the server) until the user gets bored and closes the browser. Notably, any version of IE would hit a redirect loop in the scenario above if the user had disabled cookie storage for the site in question.

If your site makes use of redirects, you should ensure that it is configured to avoid redirect loops by ensuring that any redirect that relies upon side-effects (e.g. testing or setting a cookie) is marked uncacheable.

HTTPS Caching Improvements

A few months ago, I mentioned that Internet Explorer will not reuse a previously-cached resource delivered over HTTPS until at least one secure connection to the target host has been established by the current process. This can cause previously-cached resources to be ignored, leading to unconditional network requests for content that was already in the local cache.

In IE9, the unnecessary cross-host HTTPS requests are now conditional requests, so the server can simply return a HTTP/304 Not Modified response for unchanged content. While a round-trip cost is still incurred, significant performance improvements are gained because the server does not need to retransmit the entire resource.

Back/Forward Optimization

For IE9, we’ve made improvements so that clicking the back and forward buttons results in faster performance.

RFC2616 specifically states that a browser’s Back/Forward mechanisms are not subject to cache directives:

History mechanisms and caches are different. In particular history
mechanisms SHOULD NOT try to show a semantically transparent view of
the current state of a resource. Rather, a history mechanism is meant
to show exactly what the user saw at the time when the resource was
retrieved.

By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism SHOULD display
it even if the entity has expired, unless the user has specifically
configured the agent to refresh expired history documents.

In previous versions of Internet Explorer, when the user navigated back or forward, IE would check the freshness of resources if they had been sent with the must-revalidate cache-control directive, and in numerous other circumstances depending on how recently the resource was downloaded. In IE9, the INTERNET_FLAG_FWD_BACK flag behaves as described on MSDN, and IE will not check the freshness of cached resources when the user navigates Back or Forward.

As a result of this optimization, Internet Explorer 9 can perform far fewer conditional HTTP requests when navigating with Back and Forward. For example, the following table shows the improvement when going Back to a typical article on a popular website:

	IE8	IE9	Improvement
Back/Forward Navigation	Request Count: 21 Bytes Sent: 12,475 Bytes Recv: 216,580	Request Count: 1 Bytes Sent: 325 Bytes Recv: 144,617	Request Count: -20 (-95%) Bytes Sent: -12,150 (-97.4%) Bytes Recv:-71,963 (-33.3%)

Now, I mentioned that we ignore caching directives when navigating back and forward, so alert readers may be wondering why IE9 still makes one request when clicking Back on this site. The reason is that IE will not commit to the cache any uncacheable resource. An uncacheable resource is one delivered with a Cache-Control: no-cache directive or with an Expires date in the past or an Expires date not later than the Date header. Therefore, the browser is forced to redownload such resources when the user navigates Back and Forward. To improve performance and enable a resource to be reused in Back/Forward navigation while still requiring revalidation for other uses, simply replace Cache-Control: no-cache with Cache-Control: max-age=0.

Unlike the other improvements in described in this post, back/forward optimizations are not visible in the Platform Preview build because it does not have a back button.

Heuristic Cache Improvements

Best practices recommend that web developers should specify an explicit expiration time for their content in order to ensure that the browser is able to reuse the content without making conditional HTTP requests to revalidate the content with the server. However, many sites deliver some content with no expiration information at all, relying upon the browser to use its own rules to judge the content’s freshness.

Internet Explorer allows the user to configure what should happen when content is delivered without expiration information. Inside Tools > Internet Options > Browsing history > Settings, you will see four options:

These four options have the following behavior:

These options only control the browser’s behavior when content is delivered without expiration information; if the content specifies an explicit policy (e.g. Cache-Control: max-age=3600 or Cache-Control: no-cache) then the browser will respect the server’s directive and the options here have no effect.

In earlier IE versions, the Automatic Heuristics were simple and only affected cached images, but IE9 improves the heuristics to match RFC2616’s suggested behavior:

if the response does have a Last-Modified time, the heuristic
expiration value SHOULD be no more than some fraction of the interval
since that time. A typical setting of this fraction might be 10%.

If Internet Explorer 9 retrieves a cacheable resource which does not explicitly specify its freshness lifetime, a heuristic lifetime is calculated as follows:

max-age = (DownloadTime - LastModified) * 0.1

If a Last-Modified header wasn’t present in the server’s response, then Internet Explorer will fall back to the “Once per browser session” revalidation behavior.

As a result of the improvement to heuristic caching, Internet Explorer 9 can perform far fewer conditional HTTP requests when reloading many pages. For example, the following table shows the improvement when revisiting a typical article on a popular website:

	IE8	IE9	Improvement
Revisit in new browser session (PLT2)	Request Count: 42 Bytes Sent: 26,050 Bytes Recv: 220,681	Request Count: 2 Bytes Sent: 1,134 Bytes Recv: 145,217	Request Count: -40 (-95.3%) Bytes Sent: -24,916 (-95.6%) Bytes Recv: -75,464(-34.2%)

The Caching Inspector in Fiddler will show you when a response expires, based on the headers provided on that response. For instance, here’s what you see for a response which contains an ETAG and Last-Modified header, but no expiration information:

Other Networking Improvements

In this post, I’ve enumerated the improvements in Internet Explorer’s caching code that help ensure web sites can make the most efficient possible use of the network. Of course, web developers should continue to follow best practices and specify their desired cache behavior using the Expires and Cache-Control headers, but even sites that fail to do so will load more quickly in IE9.

In a future post, I’ll describe other improvements we’ve made to the IE9 Networking Stack to further improve page load times.

-Eric Lawrence

Recently, we released a new set of demos alongside the third IE9 Platform Preview. Today we’re going to discuss the Amazon Shelf concept application (also see the companion Channel 9 video).

Much like Flickr Explorer, Amazon Shelf is written using standard HTML, CSS and Javascript. Amazon Shelf also incorporates a key new HTML5 feature – the canvas element. Canvas is an incredibly powerful way to draw directly to the screen using simple Javascript API calls.

When you launch Amazon Shelf, you’re shown a list of the top selling books from Amazon. This data is retrieved using the Amazon Product Advertising API. You can search for specific books, browse, and “open” books to view detailed information and customer reviews.

This demo uses common patterns that you find across many interactive web applications and games. There is one main loop that updates the books and other objects on the screen, and performs simple hit testing to support interacting with the elements on the canvas.

Canvas, like all graphics in IE9, is fully hardware accelerated by default. When IE9 users browse to a website that uses canvas, IE will automatically leverage the full capabilities of the PC to provide a great experience with levels of performance not possible with today’s browsers. Using IE9, Amazon Shelf is generally able to maintain a responsiveness of 60 frames per second, which is considered realtime. Today’s browsers are only able to achieve framerates of 1-8fps which is a small fraction of the performance provided by IE9.

We recently blogged about using the Windows Performance Tools to analyze browser performance. Using these tools, we’ve taken some measurements of loading Amazon Shelf in the top browsers available today. We used the same hardware and methodology discussed in the past. Let’s look at the CPU and GPU activity graphs to better understand how the demo performs in these browsers.

Note: Internet Explorer 8 is not included in this comparison since it does not support the Canvas element.

First up is Chrome 5. Chrome is able to update the screen once every 0.99 seconds, yielding a frame rate of about 1 FPS during the bookshelf load animation. This results in a very slow, choppy experience. One core on this dual core machine is fully utilized, and the GPU is not employed by the browser at all.

Here are the results for Safari 5. During the load animation, Safari does not attempt to render the scene at all, resulting in an effective 0 frames per second. Again, one core on the CPU is fully utilized and the GPU remains untouched.

Next up, Firefox 4 Beta. We used Minefield 4.0b2pre nightly for this analysis. Again, our tests ran this latest nightly build of Firefox (like all the others) in the default configuration. This means hardware rendering with the GPU was not enabled in Firefox.

Here are the results for Firefox. The animation is rendered properly, and the screen is updated twice every .25 seconds, yielding a frame rate of about 8 FPS.

Finally, let’s take a look at Internet Explorer 9 Platform Preview 3. We see that IE9’s full usage of the GPU results in a steady, smooth frame rate of 60 FPS. The CPU handles the task without any trouble and rests frequently while the GPU renders Amazon Shelf to the screen.

There is a meaningful difference in the experience when running the demo in IE9 compared to other browsers. Check out Amazon Shelf on www.ietestdrive.com to see for yourself.

We’d like to thank Amazon for their help in putting this demo together, and embracing the new GPU powered, standards based markup enabled by Internet Explorer 9.

Our team can’t wait to see what other graphically rich experiences web developers armed with hardware accelerated Canvas will dream up!

Seth McLaughlin
Program Manager for IE Performance

Canvas enables everything from basic shapes to fully interactive graphics

Canvas is a way to program graphics on the web. The <canvas> tag is an immediate mode 2d drawing surface that web developers can use to deliver things like real time graphs, animations or interactive games without requiring any extra downloads.

At the most basic level, canvas enables you to draw primitives like lines, rectangles, arcs, Bezier curves, quadratic curves, images and video like the following:

The Canvas Pad demo on the IE test drive site goes into detail on the canvas syntax and enables you to easily experiment with a wide range of examples. Feel free to make changes to any of the samples that are there to see how it works -- for example, try changing colors or sizes of things.

Taking things a step further, you can use JavaScript to animate canvas drawings or make interactive experiences. The next example draws lines as you move your mouse (or as you move your finger on touch enabled devices) over the black box. You could also choose to have your canvas experience react to keyboard input, mouse clicks or any browser event.

By utilizing the full power of the PC with hardware acceleration for graphics and fast JavaScript for animation, web developers can use IE9 to build deep, graphically rich experiences. Since canvas is an element like other elements in HTML, it participates in the page layout and its API is exposed to JavaScript so it can be fully incorporated into a web page's design. This makes it possible for sites to include things like live data visualizations, games, splash pages and ads without the need for any extra downloads or plugins.

The IE testdrive site includes several examples that demonstrate the kinds of things that sites are now able to do in an interoperable way.

Shopping

The Amazon Shelf shows what shopping for books could look like when the web site designer is able to use the kind of graphics, animations and smooth transitions that canvas enables.

Immersive game experiences:

The following demos showcase some gaming concepts like physics, character animation, collision detection and mouse interaction coupled with hardware accelerated graphics. In these demos, you'll notice that not all browsers can update the screen with the same frequency (FPS or frames per second). IE is able to maintain a high FPS by using Windows technologies to make use of your GPU - your computer's hardware that's optimized for rendering graphics.

FishIE Tank

This demo makes use of sprites to animate the fish and basic collision logic to redirect the fish when they hit the edges of the tank. It’s also good for measuring graphics performance because you can change the number of fish to increase or decrease the graphics load.

Asteroid Belt

The asteroid in the demo follows your mouse, scales and rotates. It’s an example of direct interactivity that you might find in a game.

Mr. Potato Gun

A physics engine in this demo defines how the different parts of Mr. Potato head are launched from the gun and then how they react when they bounce off the ground. Many games use some form of physics engine like this to manage particle movement and their response.

Canvas Zoom

This demo enables you to start with a very wide angle on an image like this mountain range and then zoom in very close image like people at a picnic. For games, it’s an interesting example of scaling and smooth transitions.

Demos from around the web:

There are some pretty amazing demos floating around the web and I'd like to share a couple of our favorites -- there are many more. An important part of implementing canvas is that we do it in an interoperable way so that developers can use the same markup. To help achieve this goal, we're always looking for examples that work and those that don't. A future canvas blog post will go into detail about how we work to be interoperable and what we do when there's an issue reported.

I hope you enjoy some of these canvas examples from people around the web.

Cloth Simulation

This demo is interactive and the cloth is responsive to movement and gravity.

Zwibbler

The shapes in this drawing app are preserved so you can select and then move, resize, or change their styling.

Liquid Particles

The particles in this demo are drawn to or repelled from the mouse.

Kaleidoscope

This one does a nice job of drawing you in – it’s engaging and interesting to watch the patterns as they evolve.

Nebula Visualization

The alpha blending used by this demo are really well done. The result is a cloudy atmospheric look. It’s graphics intensive and it’s still very fast and smooth in IE9.

Animated Reflection

The author of this demo says, “The script is currently using 80% of my cpu so it’s not really practical. Hopefully we will be getting JIT'd javascript sometime soon.” Well, now JavaScript is compiled in IE9. It generally uses about 1% of my CPU.

Asteroids in Canvas

This is a full game with nice graphics, collision detection, keyboard interactivity, score keeping and… green lasers.

Particle Animation

See your name in lights. This is another demo that includes a particle system. You can run this with 300 or 1500 sprites. Go ahead and bump it up to 1500.

We're looking forward to seeing the kinds visual experiences web developers will be able to build with a fully hardware accelerated browser.

Give it a try yourself. Watch the videos, get the latest platfrom preview, try out the canvas demos and build some examples of your own. If you find a bug in how canvas works or where the same markup behaves differently, please report bugs on Connect.

- Thanks, Paul Cutsinger and Jatinder Mann

Measuring real-world performance of websites is difficult and error prone today. Developers are forced to use hacks, such as injecting low resolution JavaScript timestamps throughout their code, which slows down the pages for end users, introduces an observer effect, and provides inaccurate results which can drive the wrong behavior.

The browser knows exactly how long it takes to load and execute a webpage, so we believe the right solution is for the browser to provide developers an API to access these performance results. Web developers shouldn’t have to think about how to measure performance – it should just be available for them.

It’s important for this API to be interoperable across all browsers and platforms so that developers can consistently rely on these results. The Web Timing specification at the W3C is a good foundation for solving this problem in an interoperable manner. The implementation that you’ll find in the latest IE9 platform preview is based off the navigation section of Web Timings and we’ve started conversations with the W3C and other browser manufacturers about working together to get Web Timing chartered and broadly supported.

Let’s take a closer look at how developers are forced to measure performance today and what the new API’s enable.

How Developers Measure Performance Today

Today, in order to collect performance metrics a web developer has to instrument their code with specific timing markers at strategic places on their web page. This can result in code that opposes performance best practices. Developers write something like this:

<html>
    <head>
        <script type=”text/javascript”>
        var start = (new Date).getTime();
        </script>
    </head>
    <body>
        <script type=”text/javascript”>
        /* do work here */
        var pageLoad = (new Date).getTime() - start; 
        </script>
    </body>
</html>

This approach has several problems. It forces the JavaScript engine to load earlier than normal. It forces the HTML and JavaScript parsers to switch contexts. It may block parallel requests to load the remaining resources.

Something else to mention is that this JavaScript approach does not capture network latency timings, which is the time associated from when the document is initially requested from the server to the time it arrives and is displayed to the end-user.

Additionally, while the Date function is available across all browsers, the results vary in precision. John Resig has a nice blog post in which he goes to some lengths to determine that the time from (new Date).getTime(); is as precise as 7.5ms on average across browsers, half the interval for the Windows system timer at 15ms. Many operations can execute in under 1ms which means that some measurements can have an error range of 750%!

How Developers can Measure Performance with Internet Explorer 9

The third Internet Explorer 9 platform preview contains a prototype implementation of the Web Timings NavigationTiming interface called window.msPerformance.timing. Following convention, we use a vendor prefix (ms) on the namespace because the spec is under development. There are no other implementations yet, and therefore no interoperability with other browsers. This interface captures key timing information about the load of the root document with sub-millisecond accuracy, which is immediately available from the DOM once the page had loaded.

window.msPerformance.timing

interface MSPerformanceTiming{
     readonly attribute unsigned longlong navigationStart;
     readonly attribute unsigned longlong fetchStart;
     readonly attribute unsigned longlong unloadStart;
     readonly attribute unsigned longlong unloadEnd;
     readonly attribute unsigned longlong domainLookupStart;
     readonly attribute unsigned longlong domainLookupEnd;
     readonly attribute unsigned longlong connectStart;
     readonly attribute unsigned longlong connectEnd;
     readonly attribute unsigned longlong requestStart;
     readonly attribute unsigned longlong requestEnd;
     readonly attribute unsigned longlong responseStart;
     readonly attribute unsigned longlong responseEnd;
     readonly attribute unsigned longlong domLoading;
     readonly attribute unsigned longlong domInteractive;
     readonly attribute unsigned longlong domContentLoaded;
     readonly attribute unsigned longlong domComplete;
     readonly attribute unsigned longlong loadStart;
     readonly attribute unsigned longlong loadEnd;
     readonly attribute unsigned longlong firstPaint;
     readonly attribute unsigned longlong fullyLoaded;
}

For the first time, web developers can accurately understand how long it takes to load their page on their customer’s machines. They have access to when the end-user starts navigation (navigationStart), the network latency related to loading the page (responseEnd - fetchStart), and the elapsed time to load the page within the browser.

Developers can use this information to adapt their applications at runtime for maximum performance, and they can use their favorite serialization interface to package these timings and store them on the server to establish performance trends.

With JSON, this would look something like this:

JSON.Stringify(window.msPerformance);

Another useful feature of window.msPerformance is the ability to only query for the elapsed time taken in important time phases of loading the document called timingMeasures.

window.msPerformance.timingMeasures

interface MSPerformanceTimingMeasures{
     readonly attribute unsigned longlong navigation;
     readonly attribute unsigned longlong fetch;
     readonly attribute unsigned longlong unload;
     readonly attribute unsigned longlong domainLookup;
     readonly attribute unsigned longlong connect;
     readonly attribute unsigned longlong request;
     readonly attribute unsigned longlong response;
     readonly attribute unsigned longlong domLoading;
     readonly attribute unsigned longlong domInteractive;
     readonly attribute unsigned longlong domContentLoaded;
     readonly attribute unsigned longlong domComplete;
     readonly attribute unsigned longlong load;
     readonly attribute unsigned longlong firstPaint;
     readonly attribute unsigned longlong fullyLoaded;
}

Simply access window.msPerformance.timingMeasures.navigation after the page has been loaded and you have the time taken to perform the navigation to the loaded document.

Finally, the window.msPerformance.navigation interface contains information such as the type of navigation and additional network activity that occurred on the page to help describe the overall navigation experience.

window.msPerformance.navigation

interface MSPerformanceNavigation{
     const unsigned short NAVIGATION = 0;
     const unsigned short RELOAD_BACK_FORWARD = 1;

     readonly attribute unsigned longlong type;
     readonly attribute unsigned longlong redirectedCount;
     readonly attribute unsigned longlong uniqueDomains;
     readonly attribute unsigned longlong requestCount;
     readonly attribute unsigned longlong startTime;
}

Let’s look at it in action

On the IE9 Test Drive site, you can try the window.msPerformance Test Drive demo. There you see a visualization of the time to load the demo page as shown below.

In this example, the overall navigation took 111ms to go from when the link is clicked to the time the contents are loaded within the platform preview.

Check it out!

Everything described here is available now in the third platform preview. Check it out at http://ietestdrive.com and try out the window.msPerformance Test Drive demo. This interface is a prototype of a working draft. The API may change, but we want to release this early so that developers can begin to use the API and provide feedback. Please give window.msPerformance interface a try and let us know what you think by providing feedback through the Connect.

Anderson Quach
Program Manager

Edit 6/29 - correction in sentence describing demo page load time.  Overall navigation took 111ms, not 72ms. 

As we mentioned in a recent blog post, Ecma International (the standards body behind JavaScript) is working through a process to publish a test suite for ES5. We are contributing tests to this effort, along with other companies.

In the meantime, to make it easier to try out the tests that the standards body is considering, we’re making the ES5 tests we are contributing available on the IE Testing Center.  We’re excited for the official test suite. We’re publishing our submissions to the Ecma test suite now so that the JavaScript and ES5 community can start providing feedback.

We welcome feedback on these tests via Connect. You can log in with any browser and offer comments and suggestions and bugs on the tests. These are some of the same tests that we use as part of our engineering process in developing IE9. 

As Ecma works through getting the official test suite up and running, we will publish additional tests to the IE Testing Center for the community. We will also, of course, submit these tests to the Ecma sponsored ES5 test suite.

Please visit the IE Testing Center and try them out. We look forward to reading your feedback on these tests as we work together to an official ECMAScript test suite for the community.

Thanks,
Alex Chi
Test Manager, JavaScript

As context, the industry standard that defines the JavaScript language is ECMA-262: ECMAScript Language Specification developed and published by Ecma International. Prior to last year, it had been a decade since the introduction of the Third Edition of ECMA-262 in December 1999. In December 2009 Ecma approved the Fifth Edition of ECMA-262 as the successor to the Third Edition (a Fourth Edition was never published), and last year we debuted elements of ECMAscript 5 (ES5) support when we added native JSON support in IE8. Beyond JSON, though, ES5 standardizes many significant enhancements to the JavaScript language.

New ES5 Features in the IE9 Platform Preview

There are many important ES5 features implemented in IE9 Standards Document mode:

New Array Methods. There are nine new methods that operate upon arrays. Two of them, indexOf and lastIndexOf, support searching an array for a particular value. They are similar in concept to the functions with the same names that operate upon strings. The other seven new Array methods allow arrays to be manipulated using a functional programming style. For example, the following snippet uses the new filter method to collect the elements of an array that meet a specific condition:

//a function that tests whether menu item object is enabled or disabled
function enabled(menuItem) {return menuItem.status==="enabled"};

//Assume that individual menu items have a status property and
//that a menu object has a items property which is an array.
//Create an new array containing just the enabled menu items
var enabledItems=myMenu.items.filter(enabled);

These methods support various forms of array processing without having to explicitly code for loops. In addition, they are all generic, which means that they can be applied to any object with numerically indexed properties and not just objects created using the Array constructor. You can explore demos using these methods on the IE9 Test Drive site and they are summarized in the following table:

Enhanced Object Model. The most important new feature in this area is accessor properties. These are also sometimes called “getter/setter” properties because they allow JavaScript programmers to control what happens when the program gets or sets the property value. ES5’s enhanced object model also allows programmers to control whether individual properties can have their value changed, are enumerated by for-in statements, and whether or not the property can be deleted or redefined. It also allows the programmer to control whether new properties can be added to an object. ES5 also enables JavaScript programmers to more easily create objects that inherit from specific prototype object and to inspect and manipulate the property definitions of object. All of these enhanced object model capabilities are accessible via new function properties of the Object constructor. However, note that the current release of the IE9 platform preview does not yet fully support use of these methods with DOM objects.

Other Computational Methods and Functions. In addition to the new Array and Object methods, ES5 adds or enhances several additional methods that perform useful computational operations.

ES5 also includes a number of other minor changes and technical corrections to the language. Many have no impact on most JavaScript programmers because they simply standardize minor features that have always been supported by browsers. An example of such a feature is line continuations within string literals. One minor change is of more interest. Reserved names such as if, super, and public can now be used as property names within object literals and for property access following a dot. With this change, programmers no longer need to worry about a long and arbitrary list of words that they can’t easily use as property names.

“Same Script, Same Markup”

Updating IE9’s JavaScript implementation isn’t just about supporting new ES5 features. It’s also about ensuring that web developers can use the same markup and script within IE9 that they use in other browsers. Earlier this year we released documents that describe in detail how JavaScript as implemented in IE8 differs from the ECMAScript, Third Edition Specification. In IE9 standards mode, we looked closely at these differences and made changes to ensure that IE9 can execute the same script as other browsers.

“Running the same script” isn’t just about what Internet Explorer can run. It’s also about making sure that the scripts you develop and test using IE will also run in any other standards conforming browser your users might be running. One type of issue that can interfere with this goal is unnecessary features that exist only on IE and no other browser. If a feature doesn’t provide any essential browser-specific functionality or unique value, is only implemented by a single browser, and is unlikely to ever become part of a Web standard then the existence of that feature becomes an interoperability hazard. If you inadvertently use such a feature in your script your users won’t be able to run it on any other browser.

Internet Explorer’s JavaScript implementation has historically had several features that fall into this category and we have eliminated them within IE9 Standards Mode. Generally, these are features that were conceived as usability enhancements in the earliest days of IE development. However, they were not adopted by other browsers and it is now clear that they will never be incorporated into the ECMAScript standard.

The first feature in this category is the elimination of the option to place a semi-colon after any code block. For example, IE has traditionally allowed an if statement to be coded like this:

if (conditionMet) {performTrueAlternative()};
else {performFalseAlternative()};

Note the semi-colon at the end of the first line. The ECMAScript standard has never allowed a semi-colon to occur at that position. If you try to load a script containing these lines on any browser other than IE, a syntax error will be detected and the entire script will fail to load. The original motivation for this feature was to be liberal in what IE accepts for execution – to handle some syntax errors transparently. Unfortunately, being liberal in these situations causes interoperability issues when the script runs on other browsers. In situations like this, it is better to report the error so it can be corrected by the script developer.

IE has included several extensions to function declaration syntax. One extension allows function declarations to directly define method properties of objects. For example:

function String.prototype.firstChar() {return this.substring(0,1)};

means the same thing as

String.prototype.firstChar = function (){return this.substring(0,1)};

Another extension allowed a function declaration to define multiple names for a function. Such as:

function declaration,dcl() {return processDeclaration)()};

which defines both a short name and a long name for the same function. Neither of these extensions adds any functionality that can’t already be expressed using standard features of the language, they are not part of the standard, and no other browser implements them so we are eliminating them in IE9 standards mode.

Note that this doesn’t mean we are removing all functionality that is unique to IE’s JavaScript implementation. Some features are essential for situations where a developer really does need to access some unique capability of Internet Explorer or Microsoft Windows. For example, the JavaScript features that support access to ActiveX objects fall into this category.

Testing Our Progress

A primary goal for IE9 is that the same markup can be used across browsers, which of course includes JavaScript code. So how do we know how we are progressing towards that goal? In another IEBlog post we discussed Microsoft’s position regarding standardizing JavaScript test suites. We believe the organizations responsible for web standards should also publish a definitive test suite that ensures the same script and markup works in all browsers.  There is not yet a standard test suite for JavaScript. However, the ECMAScript standards committee has agreed to develop such a suite and we are working together with the other browser vendors who are Ecma members.  That test suite is not yet complete or publically available.  In the interim, more than 1300 ES5 related tests that we use and will contribute to Ecma are available on the Internet Explorer Testing Center. As a result of the support we added for ES5, IE9 now passes all sixteen of the Acid3 tests in bucket 6 (JavaScript).

Take It Out for a Test Drive

We want your feedback. Let us know when you find JavaScript bugs. We are especially interested in interoperability issues. If you are using a standard JavaScript feature and it works differently on this Platform Preview in IE9 Standards Mode than in other browsers, you may have found a bug – report it on Connect. Because these changes only apply to IE9 Standards Mode documents, web sites running in IE9’s compatibility modes do not have these changes and continue to operate as they always have.

Finally, look very carefully at any existing code you have that does browser detection based upon known IE JavaScript differences or bugs, as these are likely to no longer work as expected in IE9 Standards Mode. This isn’t just the same old IE JavaScript.

Thanks

Allen Wirfs-Brock
Microsoft JavaScript Language Architect

The Chakra JavaScript engine in the latest Platform Preview release of Internet Explorer 9 includes significantly improved support for the ECMAScript (ECMA-262) standard, including features new to the recently finalized ECMAScript Fifth Edition (often called ES5 for short). This also includes complete support for JavaScript tests in Bucket 6 of the Acid3 test suite. Microsoft has been a key contributor to the ES5 effort. During the drafting of ES5, Microsoft was the first to provide a private reference implementation of the specification along with conformance tests to the ECMA Technical Committee 39 (TC-39).

Having the same markup work correctly across the web requires comprehensive tests that all browsers can rely on to deliver interoperable implementations. Microsoft has worked with the W3C to provide definitive test suite specifications for HTML, CSS, SVG, and other web standards. In recent months, we’ve contributed nearly 200 new tests to the W3C for these standards.

Unlike specifications governed by W3C, JavaScript does not have a definitive test suite owned and sponsored by ECMA. In the absence of such a suite, browser vendors and others have tried to fill the gap. We have published a suite of tests for new features in ECMAScript 5 through Codeplex, and will soon publish them on the Internet Explorer Testing Center. Other browser vendors have their own test suites. While all these tests are useful, they also have inconsistencies: different coverage of standards, different test harnesses, and implementation issues. Many in the industry have questioned whether we should have a more consistent way to test ECMAScript by working together.

That’s why Microsoft is now working with other browser vendors and other members of TC-39 to create an official test suite for ECMAScript sponsored by ECMA. We plan to help build this test suite, and contribute tests to it. We also welcome other browser vendors’ contributions to this effort.

Ensuring the same script works everywhere is vital to web developers. We look forward to hearing your feedback as we can continue to work on making this a reality.

Thanks,

Shanku Niyogi
General Manager, JavaScript Team

Because some browsers run on many different operating systems, there can be a tendency to use a “least common denominator” approach to implementing HTML5. By using more of the underlying operating system, and taking advantage of the power of the whole PC, IE9 enables developers to do more with HTML5. Running through Windows, instead of just on Windows, makes a big difference; the web runs more like a native application. This is consistent with our approach of architecting HTML5 support in, from the ground up, rather than just grafting in some HTML5 features.

The third Platform Preview of Internet Explorer 9, available now, continues the deep work around hardware acceleration to enable the same standards-based markup to run faster. This is the latest installment of the rhythm we started in March, delivering platform preview releases approximately every eight weeks and listening to developers. You’ll see more performance, same markup, and hardware accelerated HTML5.

This video of same markup running in IE9 and other browsers shows what hardware acceleration means for the new, graphically rich and interactive HTML5 websites to come from developers:

Note this video uses the HTML5 video tag (with the H.264 codec) if your browser supports it, and falls back to other methods otherwise. It’s a good example of same markup in action.

Performance through the power of the whole PC

Today, people expect less from a website than they do from native applications in terms of power, richness, responsiveness, and interactivity. With the third platform preview, we continue to deliver on the promise of a fully hardware accelerated browser where all of the support for text, graphics, and media uses the underlying hardware through Windows, making the full power of the PC available for the Web. Using the power of the whole PC shatters the previous constraints that limited websites.

JavaScript is one component of browser performance, and Webkit Sunspider is one measure of script performance. The latest platform preview shows how IE9’s JavaScript engine continues to get faster. Here’s the chart:

You see the progress with this zoomed-in chart, showing just the IE9 platform previews and the pre-release versions of other browsers:

Looking at the differences between the script engines’ performance, you see the performance gaps between the fastest script engines are now less than 50 milliseconds – and that’s executing several million script instructions during the benchmark test. This difference is already under any human perception threshold, and we’re not done yet.

Many sites spend lots of time in subsystems other than JavaScript. If browser performance were entirely attributable to JavaScript, the performance on the test drive site samples would look like the Webkit Sunspider graph; that’s not the case. You can expect that we will continue to focus on real-world performance and not optimize for any specific benchmark.

Introducing hardware accelerated canvas, video and audio

With the third platform preview, we introduce support for the HTML5 Canvas element. As you know our approach for standards support is informed both by developer feedback and real word usage patterns today, along with where we see the web heading. Many web developers have asked us to support this part of HTML5 and we definitely took this feedback into account as we prioritized our work.

Like all of the graphics in IE9, canvas is hardware accelerated through Windows and the GPU. Hardware accelerated canvas support in IE9 illustrates the power of native HTML5 in a browser. We’ve rebuilt the browser to use the power of your whole PC to browse the web. These extensive changes to IE9 mean websites can now take advantage of all the hardware innovation in the PC industry.

Try the Asteroid Belt sample and Fish Tank sample on the test drive site to see hardware accelerated Canvas in action. Together with Amazon, we built a book shelf sample showing the potential for bringing the richness of hardware accelerated canvas into an interactive e-commerce experience.

Similarly, we partnered with the Internet Movie Database (IMDB) to build the Video Panorama sample to demonstrate the possibilities for bringing hardware accelerated HTML5 Video and graphics interactivity together to create new applications and experiences. Our focus is on delivering a complete, highly interoperable implementation of canvas, video, and audio that makes the most of the full power of the PC.

To help you better understand how these samples work, we created videos that provide a look “under the hood” for Fish Tank, Amazon Shelf, and Video Panorama. As the browser uses more of the hardware, your experience depends on the hardware you have, just as it always has. With hardware accelerated graphics, the graphics card and driver combination play a significant role in how you experience the various examples and benchmarks.

The PC hardware ecosystem has made huge advances over the last few years. Today’s GPUs provide up to 10 times the computing power of CPUs, a clear trend in GPU processing power compared to CPU over recent years. Given how important the web is, our focus is making that power available to web developers. With IE9 developers can run the same, W3C standards-based markup as in other browsers – just faster, taking advantage of the underlying hardware. The result of using the power of the whole PC to browse is a new class of web application without many of the limits on today’s sites.

The first two platform previews demonstrated hardware acceleration of text, images, and vector graphics. Preview 3 completes the media landscape for modern websites with hardware accelerated video, audio, and canvas. Developers now have a comprehensive platform to build hardware accelerated HTML5 applications. This is the first browser that uses hardware acceleration for everything on the web page, on by default, available today for developers to start using for their modern site development.

Same Markup

As we have said before, web browsers should render the same markup – the same HTML, same CSS, and same script – in the same way. That’s simply not the case today across many browsers and many elements of markup. Enabling the same markup to work the same across different browsers is as crucial for HTML5’s success as performance. Our investments in standards and interoperability are all about enabling the same markup to just work.  When developers spend less time re-writing their sites to work across browsers they have more time to create amazing experiences on the web.

The third platform preview continues to support more of DOM and CSS3 standards that developers want. Examples here include DOM Traversal, full DOM L2 and L3 events, getComputedStyle from DOM Style, CSS3 Values and Units, and CSS3 multiple backgrounds.  And as with each previous Platform Preview, the Developer Guide includes a list of all available features. We continue to work with the standards bodies and the browser web community to deliver same markup.

Same Markup: Video, Audio, and WOFF

At MIX we showed the potential for hardware accelerated video on the web. On the test drive site you can try out several examples of IE9’s support for HTML5 video and audio tag support. You can see for yourself how sites like YouTube for HTML5 works with video playing through the GPU. Here’s an example:

Note that while the video element in the HTML5 standard does not detail support for specific codecs, developers can still use the same markup to achieve the results they want. Coding practices should focus on testing for capabilities, not browsers, and providing the right fall backs for older browsers.

Also included in the third platform preview is support for using the Web Open Font Format (WOFF) through CSS3 font face. We were excited to work with Mozilla and Opera to submit the WOFF file format to the W3C, and in IE9 to bring high quality font support to the web in a way that is friendly to web designers, font foundries, and end users. As an industry we still have work to do for same markup with same results for font support.

Like all of the text rendered in IE9, the support for WOFF makes the most of the underlying hardware and Windows DirectWrite for high quality rendering with sub-pixel precision, resulting in smooth, crisp text across font sizes and browser zoom levels. In a recent article, Richard Fink from A List Apart wrote how, “The font rendering in IE9 is worlds apart from what we’ve all come to expect.”

Of course, the importance of WOFF support is having the same markup provide the same results for text and typography - results developers and designers can depend on. Here’s an example from the test drive site that shows a selection of WOFF fonts in IE9 and in latest shipping versions Firefox and Chrome. Some of the differences you’ll see if you try this example yourself are more precise layout of text and sharper characters at large font sizes and when zoomed.

Same Markup: JavaScript and ES5

Same markup includes running the same JavaScript code with the same results. The Chakra JavaScript engine in IE9 significantly improves support for ECMA-262: ECMAScript Language Specification standard, including features new to the recently finalized Fifth Edition of ECMA-262 (often called ES5 for short). This support for ES5 includes new array and object methods, as well as other language enhancements for working with strings and dates. The test drive site includes samples where you can try new array methods and play a game built with new ES5 capabilities. You can learn more about how we used ES5 arrays with a video look “under the hood” for the Tile Switch game.

Following through on having same markup across the web requires comprehensive and consistent tests. Unlike the standards body behind CSS and HTML, the JavaScript standards body has never had a place where the community could contribute tests. We’re working as part of the “TC-39” community with Ecma to create an official test suite for ECMAScript, sponsored by Ecma. In anticipation of this site, we’re making tests available on the IE Testing Center now for feedback via Connect.

Same markup: IE Testing Center and other tests

Some people use Acid3 as a shorthand for standards. Acid3 tests about 100 fragments of a dozen different technologies. Some are still in “under construction.” Some of the patterns, like SMIL animations, are inconsistent with others, like CSS3 animations, and need to be reconciled. As we continue to implement the standards that developers have told us they value most, the Acid3 score continues to rise, and we’re not done. Here’s a screenshot of how today’s IE9 Platform Preview runs today’s Acid3 test, going from 68 in the last platform preview to 83:

With today’s update to the platform preview, we have also updated the IE Testing Center, adding another 118 test cases which we are contributing to the appropriate web standards working groups at the W3C. In addition, we have written 1309 JavaScript test cases and are making those all available to the web development community. Another blog post provides details about them.

Performance measurement in web pages

Enabling developers to accurately measure website performance is important to delivering great HTML5 applications. Today, developers can measure different aspects of performance on their own machines with the Developer Tools; they can’t, however, measure the performance their users actually experience. Today, many sites develop their own libraries that try to measure live performance on web pages. The problem is that these libraries actually slow down the pages for consumers and measure inaccurately, driving the wrong behavior for developers.

We believe that the WebTiming specification is a good conceptual foundation for solving this problem. We’re in conversations with the W3C HTML5 standards body and folks at Google and Mozilla about this, and how we can all work together to make WebTiming happen in an interoperable and standardized way, sooner rather than later.  We will work closely with the W3C and its members over the coming months to get this into an official working group and build consensus for a proposed specification while continuing to work together to ensure that the same markup works across browsers.

In order to keep making progress in the interim, we’ve included early support for these ideas in the IE9 preview. This is early work for sure, and following convention, IE uses a vendor prefix (-ms) on the namespace because the spec is genuinely under active construction. You can take a closer look at how this works in the WebTiming sample on the test drive site. We’ll talk more about this topic in a future blog post.

Test Drive IE9 Platform Preview Today

We appreciate the continued feedback about what we need to fix (at Connect, on the HTML5 testing listserv) as well as the feedback about what we’ve done right.

Our continued ask, is that you download the latest preview, try the samples on the test drive site, and try your own sites. Send IE9 the same markup that you give to other browsers. The IE7 compatibility view built into IE9, which some sites may run in, does not offer the best performance possible. If you still have sites that run in IE7 compatibility mode we recommend that you move those to IE9 standards mode. We want sites to get the full performance benefits of IE9 that come with running in IE9 standards mode. We also want your feedback from handing IE9 the same markup you hand other browsers.

The platform preview installs side by side with Internet Explorer 8 so that you can try it without replacing the full version of Internet Explorer that comes with Windows. This third release of the Internet Explorer 9 Platform Preview will install over the prior versions. There is no need to uninstall the earlier builds before installing the third.  You’ll also find more information on what’s included in this release of the Platform Preview in the Release Notes, including known and resolved issues.

Thanks

Dean Hachamovitch
General Manager, Internet Explorer

118 New Test Cases Submitted to the W3C

Today, we released an updated version of the IE9 Platform Preview build. In conjunction with implementing support for several more web standards, we developed more test cases. These new test cases are available as usual on the IE Testing Center. We’re formally submitting these 118 new test cases to the W3C for review, feedback, and inclusion into the official W3C test suites for each of these web standards.

In addition, we have written 1309 JavaScript test cases and are making those available to the web development community as well. These support Ecma-262-5, Ecma International’s ECMAScript Fifth Edition specification (also known as ES5). Ecma is currently implementing a test case submission process. When it is in place, we will submit these cases into their official process.

The IE Testing Center

One of the questions that we hear each time we write, publish, and submit new test cases to the W3C is, “How should I think about the IE Testing Center?” There are several dimensions to the IE Testing Center so I’ll go through them one-by-one.

The site

The IE Testing Center is part of the current IE project. Like we did during the IE8 project, we will make these test cases available immediately to the web community and submit these cases to the W3C working groups for inclusion into the official test suites.

There are two main tables on the IE Testing Center. The first table is merely a results rollup of the second table. The second table has links to each test case we’ve developed during the IE9 project for each standards specification.

The columns (aka Browsers)

The columns represent the most recent broadly available version of the biggest browser engines. This means Gecko, WebKit, Trident, and Presto. Given that there are two major WebKit implementations and they don’t always use the same version, Google Chrome and Apple Safari have separate columns. Based on feedback from other W3C members, we also added IE8 to the table for consistency.

The rows (aka Standards)

The rows of the first table include the core technologies that web developers have told us are most important to them when they consider the modern, under-development web technologies.

Proposed HTML5 features have received a lot of attention in recent months. In practice, the functionality described in the W3C’s HTML5 specification actually depends heavily on many other W3C specifications. To make sure that HTML5 works correctly, it’s important to test some of these other foundational technologies as well. This is basically the greater metropolitan area of “HTML5”, which includes HTML5 itself plus the suburbs of SVG 1.1 2^nd Edition, CSS3, DOM L2 and L3, and ECMAScript 5.

The second table includes links to each test case that Microsoft has submitted to each W3C working group for inclusion into their official test suites. This is a proper subset of all officially submitted cases to the working groups.

The cells (aka the results)

Each cell in the first table is a summary of the pass rate for each specification across each of the major shipping browser versions. These are contrasted with the most recent IE9 Platform Preview. The cell coloring is simply Microsoft Excel 2007’s conditional formatting Green – Yellow – Red color scale, which provides a smooth color gradient from Red to Green as the pass percentage increases.

Each cell in the second table is the test result for a specific test case on a given browser. These are simply listed as Pass/Fail and colored Green/Red, respectively.

Another question that comes up a lot is “Why is the IE9 Platform Preview so green while others aren’t?” When we make a decision to implement a given web standard, we methodically walk through the specification and start building the test cases for the spec while also building the implementation. It resembles test driven development, which works well for web standards, as long as there is a comprehensive test suite. If we fundamentally change a test case based on feedback, it usually drops the current IE9 Platform Preview’s pass rate.

Feedback on the test cases

As always, we look forward to working closely with the W3C and its members on the web standards process. If you have actionable feedback on a specific test case, please use the W3C mailing list for the appropriate working group. For JavaScript test cases, please submit your feedback using Connect. We encourage the other browser vendors to help the W3C finish the HTML5 specification by providing additional tests to the official HTML5 testing task force.

Thank you,
Jason Upton
Test Manager, Internet Explorer

Using the Windows Performance Tools you can measure not only the overall elapsed time of operations, but also look at the time spent in individual browser and operating system components. In this post we’ll show you how to use the Windows Performance Tools to record and analyze the performance of different browsers. We’ll look at how to understand Windows events, measure CPU and GPU activity, identify working set patterns, and view network activity. We wouldn’t recommend the Windows Performance Tools for the average user; however these tools are a great resource for developers and this post will help you get started using the toolset to understand browser performance.

Background

Microsoft Windows Vista and Windows 7 have an extremely low overhead infrastructure built into the operating system called Event Tracing for Windows which collects performance and system data. Event Tracing for Windows, or ETW for short, enables the Windows operating system and applications to efficiently generate events at runtime. There are hundreds of events that can be captured during execution and later analyzed by tools.

The Windows Performance Tools, or WPT for short, allow you to capture, visualize and analyze ETW traces for your operating system. WPT is part of the Windows 7 SDK and can be downloaded from here. During the installation you can scope the installation to just the “Windows Performance Toolkit”:

First Profile

Once you have the WPT tools installed, you’re ready to start analyzing browser performance.

Let’s started by measuring the performance of Internet Explorer 8 navigating to http://www.bing.com

1. Launch Internet Explorer and navigate to http://www.microsoft.com.
2. Start an elevated command prompt
3. From that command prompt execute

   xperf -start mytrace -on PerfTrack

4. Navigate IE to http://www.bing.com and wait for five seconds after the page appears to be visually done loading and the browser reaches a quiescent state.
5. Stop the trace by executing

   xperf -stop mytrace -d mytrace.etl

6. Now launch the Windows Performance Analyzer, part of the WPT toolkit, by executing

   xperfview mytrace.etl

The last command launches the Windows Performance Analyzer and opens the mytracve.etl file which contains the ETW events that were recorded during the trace.

The Windows Performance Analyzer displays the captured events. In this example you captured events from several providers. Clicking on the ‘ProviderIds’ drop down reveals the 4 providers:

• PerfTrackMetadata
• WinSATAssessment
• Microsoft-PerfTrack-IEFRAME
• Microsoft-PerfTrack-MSHTML

We will go into more detail about providers later in this post.

Notice the time scale at the bottom showing time in seconds. Next we will zoom into the cluster of events. There are two ways to zoom in: a) Ctrl + Scroll-wheel on the mouse, or b) Click + Drag to select a timespan followed by Right-Click on the selection and select ‘Zoom To Selection’.

Next, we will hover over an event to reveal its tooltip listing details about the event. For example, hovering over the first yellow dot shows its tooltip:

The EventName indicates that this event is the Navigation - Start event, which is the beginning of the navigation to bing.com. 

The tooltip of the second yellow dot reveals it as the Navigation - Redirect event. The redirect occurs because we navigated to http://bing.com and the server responds with a redirect to http://www.bing.com. As you know, it is common for sites to redirect users to the primary URL of the home page.

The third yellow dot is the Navigation - Stop event, indicating the navigation to www.bing.com is finished.

Next, we will measure the duration of the redirected navigation to get a sense of the overall time taken.

Click + Drag from the second yellow dot to the third. While dragging, the tooltip shows the duration between the two points in time:

NOTE: The elapsed time between the start and stop events is not meant for comparison among different browsers. Different browsers can name and define events as they see fit. Comparing elapsed times makes sense for a single browser. Attempting to compare them across browsers (or even different versions of the same browser) doesn’t make sense. For example, the ETW events exposed by another browser might have similar names like Navigation Start and Navigation End but they measure very different aspects of the generic term “Navigation”.

However, the elapsed time is interesting for comparing results from multiple traces of the same scenario using the same browser. For example, it is interesting to compare the navigation duration of bing.com and another site. Since the pages are very different the elapsed time will be different. Later, we will look deeper into understanding where the time is spent.

So far, we have looked at the "timeline" view displaying all events captures during the trace. We can drill into events by zooming in and looking at the tooltips of each event. Windows Performance Analyzer has more views that we will look at later.

Providers

We previously mentioned Providers that are the source of the events captured by the Windows Performance Tool Kit. In the previous example, we told xperf to capture events from the "PerfTrack" provider by specifying “PerfTrack” on the command line

xperf -start mytrace -on PerfTrack

We can use Windows Performance Tool Kit to capture and analyze every aspect of the Windows operating system. Each Windows component exposes numerous ETW events so that overall Windows has thousands of events. In addition each application can expose many more, easily leading to information overload.

Depending on the scenario that we are profiling, we chose events from a set of providers so that we focus our attention to the relevant events.

We get a listing of providers, by executing the following command:

xperf -providers

The full list has numerous providers, including Kernel Flags and Kernel Groups at the very end of the list. The following are of interest when looking at Internet Explorer:

• Microsoft-IE
• Microsoft-IEFRAME
• Microsoft-PerfTrack-IEFRAME
• Microsoft-PerfTrack-MSHTML

As well as the Kernel Group:

• Latency

We can use several user mode providers at once, for example:

xperf -start mytrace -on Microsoft-IE+Microsoft-IEFRAME+Microsoft-PerfTrack-IEFRAME+Microsoft-PerfTrack-MSHTML

To use user mode and kernel mode providers at the same time take a look at Example 2 half way down the page.

Tracing Scripts

When we analyze the performance of any component, we run performance trace many times over. To facilitate and make it easier to capture the same traces we use simple batch script. For the examples in this post we used trace.cmd:

@echo off
set session=mytrace
if not @%1@ == @@ set session=%1

xperf -start %session% -on PerfTrack
if not errorlevel 0 goto :eof

echo.
echo Performance Trace started. 
echo.
echo When done with profile actions, 

pause 

echo.
xperf -stop %session% -d %session%.etl
if not errorlevel 0 goto :eof

echo.
start xperfview %session%.etl

The basic idea of the script is:

• Launch the script from an elevated command prompt
• Reproduce the scenario that we want to capture when the script is waiting for us
• Hit any key in the command prompt to let the script finish the capture and display the result

The following is a slightly more complex script tracek.cmd that also captures kernel mode events:

@echo off
set session=mytrace
if not @%1@ == @@ set session=%1

xperf -on Latency -f %session%kernel.etl -start %session% -on Microsoft-IE+Microsoft-IEFRAME+Microsoft-PerfTrack-IEFRAME+Microsoft-PerfTrack-MSHTML -f %session%user.etl
 
if not errorlevel 0 goto :eof
 
echo.
echo Performance Trace started. 
echo.
echo When done with profile actions, 
 
pause 
 
echo.
xperf -stop %session%
if not errorlevel 0 goto :eof
xperf -stop
if not errorlevel 0 goto :eof
 
xperf -merge  %session%user.etl %session%kernel.etl %session%combined.etl
if not errorlevel 0 goto :eof
 
echo.
start xperfview %session%combined.etl

Machine Wide Perspective

When we take traces with the second “more complex” script Windows Performance Analyzer shows a holistic view of the entire system during the capture including CPU usage, CPU usage by process, Disk I/O and utilization, process lifetimes, and hard faults along with the Generic Events we looked at before. Each of the additional one can be just as important as CPU usage in determining performance.

We can select which graphs to display by clicking the black shape on the left edge which reveals the Frame List:

We can also overlay multiple graphs to get a combined view. For example, Right+ Click on a graph and select another graph under "Overlay Graph".

Summary Table

Now we will look at a very different view in Windows Performance Analyzer, the “Summary Table” view. Each graph has a “Summary Table” view that is tailored to data in the graph. For example, view the “Summary Table” view of the “Generic Events” graph via Right + Click on the “Generic Events” graph and select “Summary Table”:

We can drill down into the events by provider and reveal the individual event counts and time that they occurred.

Stack Walk

Stack walks provide another dimension when investigating performance profiles, since they let you drill down based on the "Weight", meaning approximate CPU consumed. Since the profile data is based on sampling, it is always a statistical approximation of CPU consumed.

To enable stalk walks, we need to turn them on for the events we are interested in. In this case we are interested in the profile event which is part of the Latency group. For details on enabling stack walking on the event see Stack Walking in XPerf.

A Wide World to Explore

On the IE team we use the Windows Performance Toolkit along with internal tools daily to measure and understand the runtime performance of Internet Explorer. We welcome you to download the tools and start looking at browser performance using the Windows Performance Toolkit on your own systems.

Walter vonKoch
IE Performance Program Manager

As IE changes and supports new technologies, developers will still want, in some scenarios, IE’s legacy behavior. There are many different technologies that enable developers to adjust how IE runs their site’s markup.  The main ones include the IE Developer Tool’s Browser Mode and Document Mode, X-UA-Compatible Meta tag and HTTP Header, and Conditional Comments. I’ve also updated the How IE Determines Document Modes diagram for IE9 based on suggestions from the developer community.

Browser Mode and Document Mode

Many blog comments asked about the difference between Browser mode and Document mode. There are good articles on MSDN about the Browser Mode and Document Mode menus in Developer Tools. Here’s a recap on how to use these menus to test your website.

The Browser Mode determines what User-Agent (UA) string IE sends to servers, what Document Mode IE defaults to, and how IE evaluates Conditional Comments (More on these topics below). By default, IE9’s browser mode is IE9, and IE8’s browser mode is IE8. As a developer, you can change this in IE’s Developer Tools with the “Browser Mode:” menu item. The user can change this when visiting a site by clicking on the Compatibility View (CV) button manually.  Most users opt-in to the CV List that Microsoft updates based on work with the community.

Browser Mode	Description
IE9	IE9 reports a UA string, version vector, and document mode to match the default browser behavior, which is the most standards-compliant mode in IE9. Use this mode to test how IE9 users experience your site.
IE9 Compatibility View	IE9 reports a UA string, version vector, and document mode, as if it is IE7; however, the UA string also includes the Trident/5.0 token indicating that the browser is really IE9. Use this mode to test how IE9 users experience your site if they click on the Compatibility View button. Note that the Developer Tools in the second IE9 Platform Preview has two Compatibility View options, which is a known issue.
IE8	IE9 reports a UA string, version vector, and document mode as if it is IE8. Use this mode to test how IE8 users experience your site.
IE7	IE9 reports a UA string, version vector, and document mode as if it is IE7. Use this mode to test how IE7 users experience your site.

The Document Mode dictates what mode IE’s Trident engine will render the markup in such as IE9’s Standards Mode. Changing the Document Mode refreshes the page, but does not resend the UA string or retrieve new markup from the server.

Document Mode	Description
IE9 Standards	This is the latest standards-compliant behavior available in IE9, and is the default mode used by IE9 to render a webpage that have a strict or unknown document type.
IE8 Standards	This behavior matches IE8 when it renders a webpage that has a strict or unknown doctype.
IE7 Standards	This behavior matches IE7 when it renders a webpage that has a strict or unknown doctype.
Quirks	This behavior matches IE when rendering a document with no doctype or a Quirks doctype. It is similar to the behavior of IE5 and the Quirks mode behavior of IE6, IE7 and IE8.

Changing the Document Mode for your site

As a developer, you determine the document mode that IE will use when rendering your site. By default, it’s the most interoperable and standards-compliant mode, which is IE9’s Standards mode in IE9. You can use the doctype and X-UA-Compatible Meta tag or HTTP Header to change that default as you see fit. You can use the “Document Mode:” menu item in IE’s Developer Tools, to see what mode makes the most sense for your site.

If you want to change the Document Mode for just one specific webpage, the Meta tag is the most convenient way. To change the Document mode for many pages across your site, changing the HTTP header is convenient.

IE9 will support two new X-UA-Compatible values in addition to what IE8 supports:

Meta tag or HTTP header content = “IE=______”	Description
EmulateIE9	EmulateIE9 tells IE to use the doctype to determine how to render content. Web pages with no doctype or a Quirks doctype are rendered in Quirks mode. All other doctypes are rendered in IE9’s Standards mode.
IE9	IE9 tells IE to render in IE9’s Standards mode and ignore doctype.

We’re encouraging site developers to use a standards doctype and no X-UA-Compatible Meta tag or HTTP header when targeting IE9’s Standards mode. This helps us all reach the goal of running the same standards-based markup.

If you have a legacy site that relies on IE7’s interpretation of Standards mode use the X-UA-Compatible Meta tag or HTTP header to target IE7 Standards mode. Here’s an example that combines values so that IE8 renders a webpage in IE7 Standards mode while IE9 renders the webpage in IE9’s Standards mode:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
         <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7; IE=EmulateIE9">
    </head>
    <body>
    </body>
</html>

You can achieve this result for many pages at once by changing the HTTP header to add this logic to some or all pages on Apache servers or IIS servers.

In order to help deliver on the “same markup” goal, there’s one additional change from IE8 to IE9. All iframes within a top-level page rendering in IE9’s Standards mode will also render in IE9’s Standards mode. The only exception is that iframes that specify Quirks mode will render in Quirks mode.

Detect features, not browsers (or, Avoid Conditional Comments)

We want to run the same standards-based markup as other browsers in IE9’s Standards mode. This is why we’re encouraging developers to use feature and behavior detection and the same stylesheets when targeting IE9 and other browsers’ Standards mode.

We strongly recommend feature and behavior detection rather than Conditional Comments, an IE specific feature that other browser vendors have chosen to not implement. Conditional comments will not work across browsers and are not “same markup.”

There is one case where it is appropriate to use Conditional Comments, which is for backward compatibility with IE6 or IE7 stylesheets. For example, websites such as hsn.com use Conditional Comments to load specific stylesheets in IE7.

<!--[if IE 7]>
<link rel="stylesheet" href="http://css.hsn.com/css/ie7.css?v96" type="text/css" />
<![endif]-->

IE9 will continue to support this as part of our commitment to be backward compatible for existing sites. Here are a few rules that will help you apply Conditional Comments:

• Conditional Comments are tied to the UA String by default. Using the X-UA-Compatible meta tag or HTTP header enables a page to specify a specific version for compatibility. If an X-UA-Compatible declaration exceeds the version of IE in use (8 in IE8, 9 in IE9) or is less than 7, then the value from the UA String will continue to be used instead of the version declared in X-UA-Compatible value.
• The IE version number sent in the UA String is used to evaluate Conditional Comments. This is called the Version Vector. For example, an IE7 UA String will have a Version Vector of 7 and the Conditional Comment <!--[if IE 7]> will evaluate to true. IE9 will only send one of two UA Strings; the IE9 string or the Compat View string.

  UA String	Conditional Comments evaluate against this Version Vector
  IE9	9
  Compat View	7

To summarize this section, it’s ok to use Conditional Comments to conditionally load CSS that targets IE6 or IE7. Use feature and behavior detection for everything else.

Updated diagram on How IE9 Determines Document Mode

To help illustrate how all of these features work together, we’ve updated the Determining Document Mode diagram for IE9 (in SVG or PNG) with the new X-UA-Compatible values mentioned above. We’ve also updated the diagram based on your suggestions. Thanks!

Marc Silbey
Program Manager

We believe that web application security is a shared responsibility between the browser client, web platform components (such as ASP.Net), and web applications themselves. Any shared security responsibility can potentially lead to finger-pointing whenever a vulnerability is encountered. This is why we endorse the application of declarative security features that clearly assign responsibilities at design-time.

An Example

A recent paper by UC Berkeley researchers demonstrates some very interesting flaws affecting highly complex new web platforms. One of these issues involved the use of the postMessage API supported in IE8 to post a cross-domain message with the use of a wildcard targetOrigin parameter. A targetOrigin parameter configured as a wildcard allows the message being passed to leak out to any target, without validation. This potential information disclosure threat is why the developers of the specification required targetOrigin to be explicitly set by the caller:

Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.

From: http://blogs.msdn.com/ie/archive/2008/10/06/updates-for-ajax-in-ie8-beta-2.aspx

One reason Microsoft helped participate in the working group developing the HTML5 Web Messaging specification was to ensure that the result could be implemented “secure-by-default” in products such as Internet Explorer.

We have updated our postMessage API documentation to better reflect the security implications of the targetOrigin parameter.

In this example the browser provides a primitive that, if used correctly, enables a secure platform feature. A more pointed observation is that the techniques predating the postMessage API just do not provide a reliable way to ensure messages are delivered securely.

How Declarative Security Guarantees Help

Used appropriately, declarative security features in the browser enable new scenarios while allowing web application developers to avoid potentially unreliable application-level hacks. These features ultimately help reduce some of the uncertainty and complexity around securing web applications. Rather than relying on incidental browser behavior to achieve a security objective, the browser itself explicitly provides a solution.

There are numerous declarative security features offered in modern browsers. Here is a list of a just a few:

To summarize, it is important to take full advantage of the declarative security features that the browser provides. Proper configuration of the targetOrigin parameter when using postMessage is one example. As you create and threat model web applications, rely on underlying platform technology as much as possible to help mitigate threats. Just take care in using these technologies to ensure that your security goals are ultimately met.

David Ross
Principal Security Software Engineer
Microsoft Security Response Center

We received some great feedback over the last few weeks on a number of the test cases we posted on May 5^th. I want to thank everyone who provided actionable feedback on the particular test cases. As a result, we updated 15 test cases on the IE Testing Center, submitted those updates to the W3C, and updated the results tables for the same set of browsers we listed in May. Here is the breakdown of the changes:

• CSS3 Media Queries
  • Updated 3 cases based on CSS working group feedback
• CSS3 Selectors
  • Updated 2 cases to based on CSS working group feedback
• HTML5 – Foreign Content Tests
  • Updated 10 cases based on SVG working group feedback

Thanks to everyone who provided feedback on the test cases in the W3C mailing lists.  If you have additional feedback on the test cases, please post it on the appropriate mailing list.

Thanks!
Jason Upton – Test Manager, Internet Explorer

// DON'T USE THIS
/*@cc_on
	@if( @_jscript_version < 9 )
		// Enable styling of new HTML5 elements
		...
	@end
@*/

The goal of this code is to detect and work around a missing feature. In this case the feature is styling new HTML5 elements, or more specifically, using CSS to customize the display of new HTML5 elements. As written, this code fails to run in IE9 Compatibility View and ends up leaving new HTML5 elements without styles. In IE9 Standards Mode this is not a problem as IE9 enables styling for all elements by default.

The first problem that leads to this effect is the use of JScript’s conditional compilation which is similar to conditional comments. Both of these are forms of browser detection and should generally be avoided, especially when targeting the latest version of a browser. The second and more serious problem in this code is an attempt to use the @_jscript_version statement to detect the document mode of the page. The @_jscript_version statement is actually an indicator of which version of JScript is in use by the browser as a whole. In ALL document modes of IE9, this statement currently equates to “9”. In ALL document modes of IE8 it equates to “5.8” and in IE7 it is “5.7”. Thus it is not the correct piece of information to use to determine document mode.

Fortunately, developers can determine document mode directly and robustly. A simple DOM API was introduced in IE8 that provides exactly this information: document.documentMode. Modifying the original code to make use of this API results in the following:

// Better, but still don't use
// Avoid in favor of feature detection
if(document.documentMode < 9) {
	// Enable styling of new HTML5 elements
	...
} 

This is better, but the best way to achieve the original goal is detecting directly if styling of HTML5 elements is available, and avoiding browser sniffing altogether.

Here’s how to do it:

// DO THIS: Feature detection for styling unknown elements
var elm = document.createElement("div");
elm.innerHTML = "<foo>test</foo>";
if(elm.childNodes.length !== 1) {
     // Enable styling of new HTML5 elements
     var elms = [
          "abbr","article","aside","audio","canvas","command",
          "datalist","details","figcaption","figure","footer",
          "header","hgroup","mark","meter","nav","output",
          "progress","section","summary","time","video"
     ];
     for(var i = 0; i < elms.length; i++) {
          document.createElement(elms[i]);
     }
}

Here’s how it works.

New HTML5 elements can't be styled by default in versions of IE prior to IE9 for two reasons. The first is because new HTML5 elements are treated as unknown elements. The second is that earlier versions of IE collapse all unknown elements at parse time. Being collapsed simply means that all children of an element actually become children of that element's parent. Furthermore, collapsed elements end up with separate entries in the DOM for their start and end tags. The following sample code and resulting DOM representations illustrate this point:

var elm = document.createElement("div");
elm.innerHTML = "<foo>test</foo>";

Resulting DOM in IE8

- <DIV>
	- test
	- </FOO>

Resulting DOM in IE9

- <div>
	- <foo>
		- test

As you can see, the statement elm.innerHTML = "<foo>test</foo>" actually results in two children instead of one in browsers that collapse unknown elements. This behavior can be easily identified using feature detection (e.g. testing if elm.childNodes.length !== 1).

The final piece is understanding that enabling the styling of an unknown element is as simple as calling document.createElement("unknownElementName") from script before any element of that type is encountered by the HTML parser. Thus enabling the styling of new HTML5 elements involves calling document.createElement for each new element defined by the HTML5 spec.

This approach is an excellent example of the benefits of using feature detection instead of browser sniffing. Using the above code eliminates worrying about which version of which browser supports styling new HTML5 elements. Since the code tests for the behavior itself, it will automatically apply the appropriate workaround if and only if the workaround is actually needed.

Tony Ross
Program Manager

Edit 2:28pm: edit in the third code sample.

Edit 6/11 - correction in IE8 resulting DOM description.

As a reminder, IE security updates are cumulative and contain all previously released updates for each version of Internet Explorer.

I encourage everybody to download this security update and other non-IE security updates via Windows Update or Microsoft Update. Windows users are also strongly encouraged to configure their systems for automatic updates to keep their systems current with the latest updates from Microsoft.

Tyson Storey
Program Manager

SVG Open 2010, the 8th International Conference on Scalable Vector Graphics, will be held in Paris, France from August 30 – September 1, 2010. A day of optional workshops follows on September 2^nd.

This will be the second year the IE team has attended SVG Open. Like last year, our primary purpose is to listen and learn. Of particular interest to us is how the community sees SVG evolving in light of HTML5 and CSS3 proposals around transforms, transitions, and animation.

I’ve been asked to present a keynote address which I’ve titled “From Zero to SVG in One Year—SVG 1.1 in Internet Explorer 9.” In it, I’ll describe Internet Explorer 9’s implementation of SVG and share insights from the team’s experience implementing it as part of our GPU-powered HTML5 effort. In addition, Patrick will be delivering a presentation titled “The Future of SVG and HTML5—How SVG Will Impact the Web.”

If you’re able to attend, we look forward to seeing you in Paris at the end of the summer.

Ted Johnson
IE Partner Program Manager for Web Graphics

The Meeting

The SVG Working Group has a quarterly face to face meeting. As this one was my first, I was more than happy to arrange for a place for us to meet at the Microsoft Executive Briefing Center in Brussels:

This photograph is of Bruges, a short trip to the west of Brussels. The actual meeting looked a bit different. 

Finishing SVG 1.1

During our first few days, the working group decided that we needed to close out SVG 1.1 2^nd Edition Specification. The entire group hunkered down and finished all open items and made our last edits to the spec, prepping it for the next publishing stage, Proposed Recommendation.  We are now analyzing the quality and viability of the test suite, which is the final step.

Moving Forward with SVG 2.0

After moving past the SVG 1.1 2^nd edition, the working group started to push forward on SVG 2.0.  We all agreed that we needed to approach the design of SVG 2.0 differently in order to achieve our goals.  The main principles involve scenarios and use cases, test driven feature development, and (most importantly) community feedback.

Over the next few weeks, the working group will draft scenarios and supporting features and socialize them with the community. We want to scope the work in SVG 2.0 appropriately to what will help developers the most.

Hot Topics: Modularity and SVG Fonts

There were a handful of hot topics, many of which we violently agreed on. For example, we agreed strongly about creating "optional" modules in SVG 2.0 in order to make it easier for everyone involved in web graphics to focus on the core important parts.

Modules in SVG 2.0 are more consistent with the CSS working group’s approach. They should make faster progress easier.

As Doug Schepers, the W3C Team Contact for the SVG Working Group, put it plainly we need to : "Help progress the Web Platform."  Optional modules will replace “profiles.” (Not many people understood the relationship between tiny, basic, and full within SVG 1.1.)

SVG Fonts came up as a candidate for optional status. Chris Lilley, the technical expert on the SVG Working Group officially made the proposal. The WOFF Working Group just standardized fonts, and site developers need more consistency across different web technologies. I agreed with the Firefox representative here. No one saw high demand for the scenarios. We agreed that if there’s a strong demand, we can revisit this decision.

The working group has not reached a conclusion about SVG Fonts. This discussion still goes on today. Another Mozilla person, Robert O'Callahan, recently posted a similar position about SVG fonts.

Consistency Breeds Interoperability

SVG Fonts are one of several technologies that are inconsistent between SVG and other parts of HTML5. We have a CSS/SVG Task Force to normalize features that had previously been isolated to SVG, and to expand them consistently for both HTML and SVG.

This is of course key to our primary mission of progress on the web. It’s important to have a single consistent development model for the web, one that reflects the well understood patterns, frameworks and tools used today, and provides capabilities for emerging needs of developers.

There is even more inconsistency between SVG and CSS around animations.  We all agreed that developers benefit from one consistent model here.  CSS Styling has made a lot of great progress down one path; SMIL is quite different. Reconciling these differences and commonalities between SVG and CSS features (transitions, animations, and transforms) is also part of our responsibility as a standards body working group.

Prior to going to Brussels, Doug Schepers and I exchanged an informal interview around these subjects and Internet Explorer working with the SVG Working Group.  Doug’s reaction to Internet Explorer 9’s support for SVG and his perspective on the status of SVG implementations across browsers is clear.

New Ideas for Graphics

The group also saw some new ideas for graphics; one which caught everyone's interest was diffusion curves. I was quite surprised by the quality of graphic achieved through a diffusion algorithm.  As an example, a manually rendered set of paths below demonstrates the small amount of data required to render a lifelike image.

Or the reverse where a picture was taken, and a tool reengineered the image into diffusion curves.

Graphics on the web will continue to be exciting for some time to come!

Thanks –

Patrick Dengler
Senior Program Manager

What is IE Diagnostics?

IE Diagnostics is a tool that gathers comprehensive dynamic and static data related to Internet Explorer. The data gathered is packaged up into a .cab file and stored on your machine at a location you specify. If you open the cab, you will find an IEDiag.xml file which contains detailed information related to IE add-ons, registry settings, network configurations, and more. (Click here to view a sample IE Diagnostics report). This data is invaluable when we need to debug a problem in IE without having direct access to the computer, such as, when trying to reproduce and investigate root causes of bugs reported by users.

What can I learn from an IE Diagnostics Report?

Add-ons

Imagine the following scenario: Your mom calls you up saying her IE has been running really slow for the past few days and she doesn’t know why. You suspect that the culprit is probably the last add-on she had installed but you can’t be sure until you see, first-hand, the list of add-ons installed on her machine. The problem is that she is across the country and you don’t want to spend all your mobile-to-mobile minutes debugging the issue over the phone. With an IE Diagnostics report, you can easily get all the information you need to fix the problem. All your mom has to do is save an IE Diagnostics report and send you the cab file.

Once you have the report on your machine, click on ‘View saved report’ in IE Diagnostics.

From the report formatting options, choose the “All Enabled and Disabled Add-ons” and click ‘Apply Format’. This view will show you information about every IE add-on on your machine. You can scan the Installed On column to see which was last add-on installed and easily disable it using the Manage Add-ons feature in IE.

You can also use the “All Enabled and Disabled Add-ons” format to view version numbers of various add-ons. If you know that a certain version of a particular add-on is outdated and/or causes problems in Internet Explorer, and you see that it has been installed, then you can take note of that and choose to upgrade to a newer version of that add-on or disable it. 

Crashes

An IE Diagnostics report gives you information about crashes in IE. Often times a bad add-on is the root cause of a crash in IE and an IE Diagnostics report can help you pinpoint which add-on is the actual culprit.

To get crash information, view an IE Diagnostics report that has been saved on your machine and from the drop down of applicable formats, choose the “Events” viewer. In the list displayed, scan for entries where Provider = “Windows Error Reporting” and Event Name (under Message) = “APPCRASH”. If such an entry is found, get the filename in position P4 under the Problem signature portion of the Message. This will be the name of the add-on binary (most likely) causing IE to crash.

If you know which add-on the binary is associated to, you can go into Manage add-ons to disable the particular add-on. If you can’t tell which add-on the binary is part of, then you can pull up the “All Enabled and Disabled add-ons” view for an IE Diagnostics report, scan the module name column for the filename in question and see which add-on (in the name column) it corresponds to.

Security Zone Settings

An IE Diagnostics report allows you to view your security settings in all zones (local machine, Intranet, Internet, Trusted, Restricted) at a glance and compare changes you made to what the default settings were when you first installed IE. If your computer is infected with Malware, oftentimes security zone settings are compromised, as this user discovered.  The zone view in IE Diagnostics is useful when you want to know which settings have changed from the default so you can undo specific ones without having to Reset IE and undo all other configuration changes.

To view security zone settings, view an IE Diagnostics report that has been saved on your machine and from the drop down of applicable formats, choose the “Zone View” viewer and click ‘Apply Format’. This displays settings in each zone- both settings for the machine and those for the particular user - for all security options in Internet Options. You can scan pairs of columns (for example, Intranet vs. userIntranet) to see if there are any differences between what you (the user) have set  vs. what was default on the machine.

Browsing Issues

The live network capture feature of IE Diagnostics allows you to debug broken functionality on a website. By enabling the Network Captures feature in an IE Diagnostics report you can capture network traffic, view and analyze it to identify any potential issues. This is especially useful in remote debugging scenarios where you don’t have direct access to a user’s (like your mom’s) machine to run fiddler traces or use the new Network tab in IE9 Dev Tools.

Some things to look out for in network capture data include:

1. Cookies being passed, for session related issues – cookie related issues are typically seen when people are unable to successfully login to a website even when using the correct credentials
2. Websites 302 or 303 redirects - examples here include why a particular site is not rendered in Compat View even though it is in the user's Compatibility View List (e.g. example.com does a 302 redirect to say, example2.com so the domain that should be added to the CV List should be example2.com!)
3. Cache related issues to see which resource is refreshed - IE may not see certain dynamic page updates occur, if they are not refreshed correctly, and a network trace helps dig deeper into why this is the case- for example, a trace will tell you when a cached page is set to expire and will be re-downloaded from the server.
4. Network hangs to see if the client is waiting on the server or vice versa.
5. Watch AJAX activity- to see if HTTP requests and responses are being sent across the wire as expected
6. Examine to see if HTTP compression is being used- knowing whether compression is being used may help you diagnose problems of this nature.

What data is stored in an IE Diagnostics report?

When you look at an IEDiag.xml report for the first time, you’ll notice the sheer volume of data collected. This section describes exactly what is in an IE Diagnostics report.

IE Diagnostics contains 2 major tool sets to perform its operations:

Data Collectors: Collects static data such as Registry settings, Set up info, Installed add-ons and DxDiag output.

Captures: Collects Network and/or Process information dynamically as you browse the web using Internet Explorer or Internet Explorer Platform Preview.

By default, when you choose to save an IE Diagnostics report, the tool will collect only static data unless you opt-in to collect dynamic data by enabling one (or both) of the captures. For more information on how to run IE Diagnostics to gather Captures data, please refer to the IE Diagnostics User Guide.

Data Collectors

IE Diagnostics contains eight Data Collector tools that gather exhaustive data about your machine settings and operating environment.

• Add-ons Enumerator: The Add-ons Data Collector looks in known locations of the registry and gathers information about all the add-ons, extensions, toolbars and BHOs currently installed for IE. This is meta information about the add-ons such as, the add-on type, version number, publisher, and whether the add-on is enabled or disabled.
• DxDiag: The DxDiag data collector runs the DxDiag tool in Windows Vista and Windows 7 and gathers the output. This data collector generates a comprehensive report containing information about DirectX components and drivers installed on your system. You can access the DxDiag tool on your machine by typing DxDiag in Windows Search (or you can run the application from C:\Windows\System32\dxdiag.exe). More information about DxDiag can be found here.
• Event Log Information: The Event Log Data Collector looks through the Application event log, searching for all the events that related to IE. It picks up all application errors and Windows Error Reporting buckets. The criteria used in selecting events are simply if the string “iexplore.exe” or “iepreview.exe” (for IEDiag in Platform Previews) exists in the message portion of the event.  It keeps the most recent 100 events.
• File Information: The file information data collector gathers metadata like file size, creation time, attributes and last write time for a set of files related to IE that are guaranteed to be present on your machine with any IE installation.
• Networking: The networking data collector gathers information about your current network settings. It collects static network data, for example, the output from running IPConfig -all and data about the operational network adapters on your machine and their IP addresses. It also gathers data to help diagnose the health of your network connection. For example, it pings the www.windowsupdate.com server to see if there is any activity over the network. This is useful information when debugging a scenario where you do not have physical access to a machine and are trying to debug an error of the “Page cannot be displayed” variety, where you are able to connect to the internet but see that no packets are being transferred. An accidentally misconfigured firewall or malicious software that corrupted Windows socket settings can be detected from this section of an IEDiag log report as well.
• Registry Settings: The registry settings data collector gathers a mass of registry settings information under the Internet Explorer and Internet Settings hives.
• Security Settings: The security settings data collector gathers the ACLs of Favorites, Cookies, Internet Cache, and History in Internet Explorer.
• Setup Information: This data collector collects various set-up log files generated during the course of an IE install. Copies of files gathered by this data collector are included in the .cab file generated by IEDiag. These files can help diagnose installation issues.

Captures

IE Diagnostics contains two capture tools that collect data specific to your browsing activity within the time range you specify. The best way to get the most detailed diagnostic information when debugging a specific browsing scenario is by enabling the capture tools. The depth of data gathered around the specific problem you are experiencing makes pin-pointing the root cause of the issue that much easier.

• Network Capture: This feature runs Unified tracing (on Windows 7) or Netmon 3.3 (on Vista if installed) to get a complete trace of network activity while you are reproducing an issue in IE.

  The official Netmon blog has many tips and tricks on troubleshooting network problems and using Netmon. There are also helpful videos on channel 9 on the same topic.

  Note: If you are on the Windows Vista operating system, you may not see the Network Capture feature in IE Diagnostics if you don’t have Netmon 3.3 installed. You can install Netmon 3.3 from here.

• Process Logger: The process logger feature captures the creation, modification and deletion of system events during the time span that the feature is running. For each process, the tool will gather its name and creation, modification or deletion time, and more.

Summary

As mentioned previously, IE Diagnostics reports are extremely valuable in remote debugging scenarios- when one doesn’t have immediate access to the faulty machine. We urge you to include an IE Diagnostics report with your bug submission on Connect. IE Diagnostics reports contain valuable information that helps the IE team reproduce issues reported by you, and find and fix them faster. For more information on how to generate an IE Diagnostics report, please refer to the user guide.

Thanks!
Swathi Ganapathi
Program Manager

Flickr Explorer is written using standard HTML, CSS and JavaScript. It uses AJAX to asynchronously search Flickr based on your search terms and display image results through an interactive and visually compelling experience. You can zoom in, pan around, and open each photo’s Flickr page with by control+clicking.

With Internet Explorer 9, Flickr Explorer is generally able to maintain a near real-time responsiveness of 52fps (52 frames per second). In contrast, other browsers struggle to maintain 4-8fps, which is barely 15% the performance that Internet Explorer 9 provides in this particular scenario.

As we discussed last month in a post on the Flying Images demo, we redesigned the core of Internet Explorer 9 to be fully hardware accelerated. Internet Explorer 9’s display rendering subsystem uses the GPU for all graphics and text on web pages. Internet Explorer 9 moves graphics work that has traditionally occurred on the general purpose CPU to faster, more specialized hardware. Internet Explorer 9’s JavaScript engine takes advantage of multiple-processor cores to background compile JavaScript into machine code. Internet Explorer 9 uses modern processor instruction sets across the entire product. Taken together, these changes enable computations to occur faster and in parallel, freeing the CPU to spend time performing other operations.

Let’s take a closer look at the CPU and GPU activity graphs collected while running the Flickr Explorer sample to see more hardware acceleration in action. These traces were captured while zooming in on a selected Flickr photo, and use the same machine and methodology that we previously discussed.

First, results from Internet Explorer 8 are shown below. Like we saw with the earlier Flying Images demo, Internet Explorer 8 utilizes an entire CPU core (50% of this dual core machine) to animate the images on screen. Internet Explorer 8 does not utilize the GPU in this scenario.

Internet Explorer 8 can barely make one screen update every 0.253 seconds, which results in roughly 3.9 frames per second (FPS). This is clearly a very poor experience for the user.

Next, let’s check out how the new Chrome 5 beta handles this task. As you can see below, it doesn’t fare much better than Internet Explorer 8. Chrome is able to update the screen every 0.222 seconds, achieving a frame rate of about 4.5 FPS. Again, this results in a very choppy and undesirable experience. Chrome also does not utilize the GPU in this scenario.

Safari 4 handles the demo similarly to Chrome, earning a slightly lower frame rate of 4.2 FPS. Again with Safari, the GPU remains unused while the CPU remains a bottleneck.

Next, let’s take a look at Firefox. We used the most recently Firefox nightly build, Minefield 3.7a5, for this analysis. Like each other browser tested, we ran Minefield in its default configuration (which means hardware rendering with D2D was not enabled). We will post comparisons with Firefox’s hardware acceleration when it’s on by default in their beta.

Firefox handles the demo much better than Chrome and Safari. The screen gets updated roughly once every 0.12 seconds, which results in a frame rate of about 8.3 FPS. While this is nearly double the score of Chrome, it is still quite slow and barely usable.

Finally, the results from Internet Explorer 9 Platform Preview 2 are shown below.  We can see that, unlike with the other browsers, the CPU handles this task with ease and has periods of frequent rest where Internet Explorer and your applications can performance additional operations, while the GPU renders Flickr Explorer to the screen.

Internet Explorer 9 is able to update the screen once every 0.019 seconds on this mid-range configuration, which equals a frame rate of about 52 FPS.

When you play with the demo, the difference between Internet Explorer 9 and other browsers is crystal clear. While you can easily zoom in, out, and pan through the Flickr photos with Internet Explorer 9, it’s difficult to do this with the other browsers.

We’d like to extend a special thanks to the Flickr team for building such a simple, easy to consume services API. We were able to put this sample together in a couple of days using the same APIs that web developers program against today. The only difference is that we have higher expectations for the types of application that you can build through standard markup and these APIs.

We’re excited to see what new experiences web developers will create with IE9’s hardware acceleration!

Seth McLaughlin
Program Manager for IE Performance

An add-on using WinINET to issue HTTP requests can suppress default cookie behavior by passing the flag INTERNET_FLAG_NO_COOKIES, which will suppress automatic sending and storage of cookies.

INTERNET_FLAG_NO_COOKIES

0x00080000

Does not automatically add cookie headers to requests, and does not automatically add returned cookies to the cookie database.

If the add-on is making HTTP requests using URLMon, it can pass BINDF2_DISABLEAUTOCOOKIEHANDLING in the bind flags.

BINDF2_DISABLEAUTOCOOKIEHANDLING

Do not automatically add cookie headers to requests, and do not automatically add returned cookies to the cookie database. Setting this flag adds the Microsoft Win32 Internet (WinInet) flag INTERNET_FLAG_NO_COOKIES on the current moniker binding. You can still set cookies manually on the request, and read them from the response.

If the add-on wants to use a higher-level construct and the server supports Access-Control, IE8 offers the XDomainRequest object which suppresses cookies and authentication automatically.

If the add-on is hosting a Web Browser Control, it can implement an IInternetSecurityManager and/or the WinINET Privacy functions for fine-grained control over cookie behavior. Alternatively, the add-on could choose to make its HTTP requests using WinHTTP (which doesn’t support automatic handling of cookies at all).

Beyond the existing APIs to control whether or not cookies are sent along with HTTP requests, Internet Explorer 8 exposes new Privacy APIs to allow add-ons to support Delete Browsing History and become InPrivate Browsing-aware.

Thanks for your help in respecting users’ privacy!

Eric Lawrence
Program Manager

When users can stay in control of their browser and their information, everyone is better off.   The IE guidelines and requirements are designed not only to aid in easier and faster development of add-ons but also to prioritize user control and protection of privacy.  As a result, when developers consistently follow the guidelines and requirements, users have a better experience.

Google recently released a new version of their Google Toolbar for Internet Explorer (and started their auto-updating process) with a few improvements worth noting:

• Pressing the toolbar close button now offers an option to disable the Google Toolbar permanently, not just hide it. Previous versions allowed users to hide the toolbar, but the toolbar code still ran. Selecting the close button option in the new version displays a close dialog for the Google Toolbar, which is consistent with the default toolbar disable experience in IE8.
• The Google Toolbar no longer modifies the IE new tab page, resulting in a predictable new tab experience for users.

Many thanks to the Google Toolbar team for their work here. We’re encouraged to see more add-on developers (following the Crawler Toolbar and AVG Security Toolbar) provide more predictable, reliable experiences for our shared customers. Developers contribute to a consistent and reliable experience in IE when they use only the supported, documented extensibility points.

- Marc Silbey and Herman Ng

In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows.

As we said at MIX recently, when it comes to HTML5, we’re all in. This level of commitment applies to the video codecs that IE9 will support as well. We are strongly committed to making sure that in IE9 you can safely view all types of content in all widely used formats. At the same time, Windows customers, developers, and site owners also want assurances that they are protected from IP rights issues when using IE9.

We have technical specifics to work through. We want to be clear about our intent to support the same markup in the open and interoperable web, and to do so in a manner consistent with our view of safety and security.

In the meantime, in choosing a video codec, customers and partners have many issues to consider.

Today, hardware support is widely available for H.264 both on PCs and phones. (You can read about the benefits of hardware acceleration here, or see an example of the benefits at the 26:35 mark here.) Codecs have been a source of security and reliability issues (link1, link2, link3, link4) for some users. New code often faces security issues; the H.264 codec in Windows 7 has been in broad use for some time now. Sites also need to think about the issues in supporting multiple formats.

As this article points out, the issue of potential patent liability is “ultimately for the courts to decide.” Some web groups have cited concerns about patent issues with similar codecs and the costs that may be associated with shipping codecs not covered by patent licenses. At the same time, there’s been community discussion about the lack of H.264 support in some browsers, for example here (via a comment on the IE blog).

Again, we want to be clear about our intent to support the same markup in the open and interoperable web. We are strongly committed to making sure that in IE9 you can safely view all types of content in all widely used formats. When it comes to video and HTML5, we’re all in. In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows.

Thanks,
Dean Hachamovitch
General Manager, Internet Explorer

Note: as we said in our prior post, comments are not available on the IE blog this week due to a system upgrade.  We always want your thoughts and feedback, so we cross-published this post on the Windows blog. If you want to comment on this post, click here.

Articles referenced in this post:
Apple QuickTime H.264 Movie File Remote Code Execution Vulnerability
Benefits of GPU-powered HTML5
Bugzilla@Mozilla – Bug 435339 (at comment 60)
Bugzilla@Mozilla – Bug 435339 (at comment 79)
How Much Web Video Is iPad-Ready? About Two-Thirds. Really.
HTML5 video: Browser support (Wikipedia)
IEBlog : Follow Up on HTML5 Video in IE9
IEBlog : Follow Up on HTML5 Video in IE9 (comment)
IEBlog : HTML5 Video
Keynote Day 2 :: Sessions :: Microsoft MIX10 (at the 26:35 mark)
Know Your Rights: H.264, patent licensing, and you -- Engadget
Microsoft fires back at critics of its HTML5 strategy | ZDNet
Microsoft Intellectual Property Expansion: Frequently Asked Questions Nov. 10, 2004
Public Advisory: 04.09.10 // iDefense Labs
SecuriTeam - Apple QuickTime H.264 Nal Unit Length Heap Overflow Vulnerability
Use of Ogg formats in HTML5 (citation reference) (Wikipedia)
[whatwg] Removal of Ogg is *preposterous*"

Edit 2pm: typo correction in the 4th paragraph.