The platform previews show the focus in IE9 on performance, interoperable HTML5 through same markup, and hardware acceleration. We’ve also posted here about the work we’ve done with add-on developers, and we shared some data about add-on performance and how we measure it.

In this post, we cover more of our thinking about measuring add-on performance and how to help consumers to stay in control of their browsing experience.

Add-on Performance and Site Performance

We’ve written about the different dimensions of performance in the web platform. We have also talked about the role add-ons play in overall browser performance. Site developers want a reliable, fast platform to run their web sites. Consumers (site visitors) want a reliable, fast experience of those sites. The perception of site speed includes the user’s experience of the site, the browser, and the installed add-ons.

As discussed in Add-on Performance part 1, add-ons can have a material impact on site performance and the consumer experience. Our goal with IE is that users have everything they need to make informed decisions and remain in control of their browsing experience.

Measuring performance to inform decisions

It is important that people stay in control of their browsing experience. This includes many aspects of using the browser including downloads, privacy, security, and controlling which add-ons to use. The ideal experience allows people to have exactly the add-ons they want – no more no less.

For users, there is a basic cost to benefit decision to make with add-ons. To make an informed decision, the user needs to have a clear view on the costs of the add-on as well as the apparent benefits. Most people understand the benefit they get from using an add-on they choose to install. It is more difficult to understand the full cost that add-ons bring to your browsing experience in terms of performance, responsiveness, and reliability.

When we introduced Web Slices, Accelerators and updates to search providers in IE8 we started a pattern of making sure that people are in control of the add-on capabilities in their browser. These types of declarative add-ons do not have performance or reliability costs to the browsing experience. The main impact they have is taking up space in the favorites bar or right click menu. Sites can promote web slices or add-ons, and the user is in control to decide whether to add them or not. This is an important part of the add-on experience even for savvy users; namely that people must consent to have the add-on.

For the types of add-ons that do have a potential performance and reliability cost (toolbars and BHOs), the user needs additional information. IE8 users can see the load time for add-ons in the Manage add-ons dialog. This is a good start, but there is more IE can do to help people fully understand the impact an add-on has on browsing performance.

Ideally IE would measure both load time and the additional time it takes to navigate to sites (navigation time). Measuring this time for every navigation, including the first time the add-on runs, is crucial because it represents how long the user actually had to wait to load IE and navigate to their favorite sites on their PC.

An important part of informing users is providing a threshold to understand the impact of add-ons have on performance. No matter what hardware you’re running on - from low end netbooks which throttle the CPU for long battery life or high end gaming desktops – human perception thresholds don’t change. Several studies regarding website response time report that users notice any delay over 0.2 seconds. Actions that are faster than 0.2 seconds appear instantaneous.  Scenarios with response times slower than that threshold can feel “slow” to users. Of course, the individual person should be free to choose a different threshold that matches their particular browsing needs.

When considering the performance of add-ons, it is useful to do so in relationship to this threshold. People think about the speed of actions in the browser, like opening a new site, rather than the speed of individual add-ons, so what matters to the user is the total amount of time taken by add-ons. From the user’s point of view, they don’t care if it’s one add-on taking 2 seconds or 10 add-ons each taking 0.2 seconds. Informing users means providing the visibility on everything that is contributing to the performance they experience, with enough detail that the user stays in control. With this information people can make decisions about individual add-ons in the context of all the other add-ons that they’re running.

A personal decision

In part 1 of this series we shared statistical data about add-on performance which is compiled from people who opt into sending telemetry. Because this data is anonymous it’s useful for spotting broad trends and working with add-on partners but it’s not useful for helping a specific person in their environment. What matters to a person is what happens on his or her own machine. So, they need data that’s specifically about their add-ons on their machine with their browsing habits; purely local data. This enables them to make the most informed decision about the add-ons they use and to stay in control over their browsing experience

With this information, the user can make an informed choice. They understand the value of the add-on features and the performance implications. People may decide that an add-on is so valuable that they’re willing to wait a ¼ second or even a ½ second during their browsing. People may also decide that they don’t utilize the features of a particular add-on frequently so they disable it until they want it. Consistent with other browsers, IE makes re-enabling add-ons easy through the Manage add-ons dialog. The most popular entry point is in the right-click menu of the command bar but it can also be accessed from the tools menu, the right click menu for a page (under accelerators), the search box dropdown menu (under search providers), windows control panel and of course from the options dialog. Microsoft doesn’t share information with developers about individual users disabling or enabling add-ons in keeping with our privacy policy. Using add-ons is a personal choice, so IE never automatically enables or disables an add-on – the user is in control and they choose which to enable and which to disable. IE gives people the information they need to make an informed decision.

More details for add-on developers

For background, we’ve talked about using windows tools to measure load and navigation performance of add-ons. Here’s more detail about the load and navigation measurements so add-on developers can test the performance of their products or do something more like build capabilities into their products to detect when browsing is slowed and tune the add-on experience appropriately.

Add-on Load time (Load Time)

IE8 measures load time when a new tab is created and IE initializes all enabled add-ons (and IE9 will do this too). IE calls CoCreateInstance(), ShowDW() and SetSite() for each add-on. In IE8, an add-on’s load time is the total time it takes to return from the CoCreateInstance() and SetSite() calls. In the future, we’ll also measure the ShowDW() function call.

Webpage Navigation (Navigation Time)

Earlier in this post, we talked about the importance of measuring navigation time. Here’s how we do it on the IE team and how we recommend add-on developers do it. An add-on’s navigation time is the time it takes to handle the following three DWebBrowser2 events while navigating to a webpage:

• BeforeNavigate
• NavigateComplete
• DocumentComplete

We start measuring a navigation time for all enabled add-ons once IE fires a top-level BeforeNavigate event.

Sites may cause several navigation events to fire as they download images or content in frames. So, we keep an open tally of the time the add-ons take for each event on that page until the user:

• Navigates (another top-level BeforeNavigate)
• Cancels the navigation
• Closes the tab
• Closes IE

Once that occurs, we append the navigation time data point for each of the add-ons to the list.

When showing the load or navigation time data to users, we average up to the last 10 data points. We don’t measure the performance of disabled add-ons since they aren’t running or taking any time to load or navigate. Instead we show the latest data we have in parenthesis to inform the enable decision for people.

In everything we do including add-on performance measurement, IE treats all add-ons from all developers the same. Only the user makes decisions to enable or disable add-ons.

Thanks,
Herman Ng

Edit on 8/31 - replaced ExtensionShowDW with ShowDW() and refer to it as a function call rather than an event in 'Add-on Load time (Load Time)' paragraph.  Also removed extra period.

Testing SVG

The W3C SVG Test Suites attempt to “test” the ability to implement the spec, but as we learned in the working group, this is not enough to guarantee an interoperable set where a developer can use the same markup that works across all browsers. The SVG Test Suite is not intended to test conformance, but rather whether or not the spec can be implemented. From the W3C SVG Test Wiki:

“Our test suites are necessary, but not sufficient, to test conformance… Thus, representations of tested support is skewed toward the more complex features of SVG, and is not an accurate view of overall SVG support”

In other words, the existing test suite doesn’t test whether a browser conforms to the spec. To this end, we are working closely with the SVG Working Group to help round out these tests; in fact, there is an external effort to create an SVG DOM 1.1 conformance test by the SVG Interest Group. At the time of writing, IE9 passes 100% of these automated tests. In concert with the SVG Working Group, we are helping to resolve these interoperability issues by continuing to enhance the SVG Test Suite through regular contributions.

Additionally, there exists an imbalance between the number of requirements in the modules in the SVG Specification, and the number of tests in the SVG Test Suite that represent those requirements. The Internet Explorer team helps to address this imbalance through test asset contributions. But this is not enough. We have contributed 56 tests and expect to continue to deliver more over time.

Test Driving SVG

The better measure of conformance and more importantly interoperability was do develop more complex SVG for the web. My own experience in test driving SVG by developing the SVG Dice demo illustrates some of the places where we have more work to do as a community on interoperability of SVG.

The SVG specification contains over 2000 individual requirements. This is a large number in comparison to other web specifications and means that there is plenty of room for different interpretations. We strive in the SVG W3C Working Group to identify these differences. When I developed the SVG demo with the requirement that it works across browsers, my eyes were opened to some of the difficulties web developers face.

Most of the interoperability issues stem from a combination of the large number of requirements, the dependencies on other specifications, and the lack of significant content on the web to ensure the features are interpreted the same by both developer and browser vendors alike. SVG is relatively new ground for web developers and whereas HTML and CSS have enjoyed decades of refinement by a large scale of users, SVG has not yet had the same level of use and scrutiny.

Now that SVG is a part of HTML5, we expect to see traditional web developers learning new and better ways to improve experiences for their users using vector graphics. At the last SVG Face to Face meeting, the SVG Working Group assembled scenarios for SVG that provide for more targeted use cases for the next generation, graphical web. SVG plays an integral role here.

Comparing Implementations

I wrote the SVG Dice demo from my own understanding of the specification using Internet Explorer 9 and subsequently tested it in other browsers. In most cases where I ran into conflicting behavior, at least two browsers still agreed. Sometimes Internet Explorer’s behavior matched Chrome or Safari, and other times it matched Firefox or Opera. Because Internet Explorer is the most recent implementation, it benefits from an SVG Specification that is in last call where at least some of the ambiguities and conflicts have been resolved in the specification. Clearly there are more.

Something that caught me off guard was the impact of performance on my development effort.

From a developer’s perspective, I wanted to use the same graphic features like opacity, gradients, and masks in all browsers, in order to provide a consistent interoperable user experience, but I couldn’t do that because of performance concerns. Fully hardware accelerated graphics on Windows helps to move these graphic intensive computations to the GPU. I added the “Low Fidelity” mode to enable users to experience this demo in browsers that don’t make full use of the GPU. One nice side effect is that this also demonstrates CSS styling of SVG.

The Surprising “Switching Event”

Debugging the differences between browsers caused a very interesting “switching event” for me as a developer. There were a few outstanding bugs in the IE9 debugging tools (now fixed) which prevented me from placing breakpoints in code when working with SVG, so I used the popular Firebug add-on for Firefox. However, running the demo on Firefox was too slow, so I reverted back to Internet Explorer 9 to debug.

I eventually found work-arounds for most of the incompatibilities without having to write browser specific code, but it required far more effort than expected or considered reasonable.  We have more work to do here as a community in building the promise of same markup for SVG.

The Code

Because SVG is an older spec but new to a lot of developers, I thought I would review some of the code and concepts in this demo up close.

The Document Structure

As a first example, most browsers do not yet support SVG in HTML5.  I had to structure the document as XHTML with inline SVG.

<!DOCTYPE html>
<html id="demohtml" xmlns="http://www.w3.org/1999/xhtml" class="testdrive">
  <head>
    <title>
      SVG Dice
    </title>
  </head>
  <body id="demobody" onload="Setup()">
    <audio id="sndRemove" volume="1" src="assets/remove.mp3" preload="true"  ></audio>
    <svg  overflow="visible" id="theSVG" xmlns=http://www.w3.org/2000/svg
         xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" >
    </svg>
  </body>
</html>
    

The above simple <!DOCTYPE html> sets Internet Explorer 9 to run in “standards mode” where SVG is supported. Notice that the SVG is embedded directly into the HTML. Both the css and the script are linked in via the HTML elements as expected.

<script type="text/javascript" src="demo.js"></script>
<link rel="Stylesheet" type="text/css" href="demo.css" />

At this point I have my basic html and svg document, stylesheet, script file structures. Next I need to build the graphical elements, provide the styles and write the script necessary for the animations and user experience.

Adding the Content

One of the great benefits and unique nature of the web development community is what we called the “copy/paste” use case. Any developer can readily search Wikimedia for public domain SVG art and use these directly in their applications or on their sites. Other popular tools exist for generating new or modifying existing content, from the open source Inkscape which focuses specifically on SVG, to other graphic tools from Microsoft and Adobe which export to SVG. I used existing open source clip art for the dice and for the boat.

Initially I had kept these SVG sources in different files for the purpose of separation. Unfortunately, I ran into several different issues across browsers from sizing to SVG Images support, which forced me to include all of the SVG in the one HTML file.

SVG contains the concept of <defs>, which is used to define an element(s) with styles and attributes, that can be re <use>d later. These two concepts are very powerful. They allow me to create many different sized dice for use as the image on the cup, those that fall into the cup, or those that roll across the screen during game play. I organized the <defs> from the various files at the top document immediately after the SVG tag.

<defs>
    <!-- for left die -->
    <linearGradient id="grad21" x1=".445" x2=".554" y1=".442" y2=".555">
        <stop stop-opacity=".9" offset="0" stop-color="#470808"/>
        <stop stop-opacity=".9" offset=".65" stop-color="#700d0d"/>
        <stop stop-opacity=".9" offset="1" stop-color="#8c1111"/>
    </linearGradient>
</defs>

These <defs> are later referenced:

<!-- edges -->
<path d="M 2474 4434 L 4860 2945 C 5009 " fill="url(#grad21)"/>

Once the <defs> were in place and the main clipart content was inline, I designed the rest of the experience, keeping in mind that SVG renders in layers from top to bottom. The majority of the remaining content was the scoreboard, the felt, the text and the cup.

Adding the User Interactivity and Animations

One of the more challenging aspects of this demo was organizing the sizing. One of the first things I do in the code is register the resize event, and set up the dimensions of the <svg> and the contained svg fragments. For simplicity, I <g>rouped them so I can apply scaling and positioning individually.

document.getElementById("theSVG").setAttribute("width", surfaceWidth.toString() + "px");

Something to take notice of immediately here is that this JavaScript code is familiar to web developers because it is standard JavaScript working with the DOM. SVG has its own DOM methods which I use, but I mostly stick to DOM Level 2 constructs as there is general agreement in the SVG Working Group that the SVG DOM might need revisiting.

Next I needed to take both of the static dice as SVG Fragments, and create some code to clone them, store references in an array with properties that allow me to manipulate their transforms for the animation effects, as well as ensure the physics engine recognizes them accordingly. The loop to create the dice is straightforward; it loops through the number of dice desired, clones the original into the DOM and creates an array to manage them.

Note: Most code samples here are trimmed for brevity, but all of the code is on the Platform Preview site http://ie.microsoft.com/testdrive/Performance/SVGDice/Default.xhtml)

First I clone the prototype and add it to the DOM, setting some default attributes along the way. Note the establishment of the transform is used to move the dice (translate), rotate the dice (rotate) and size the dice (scale).

// create an instance of die #1 and add it to the SVG Doc
this.die1 = createElement("g");
var tmpChild = this.die1.appendChild(createElement("g"));
var tmpNode = this.die1.appendChild(tmpChild);
tmpNode.appendChild(nodeDie1.cloneNode(true));
// set some default attributes
this.die1.setAttribute("id", "die_1_" + number.toString());
this.die1.setAttribute("transform", 
    "translate(" + this.x.toString() + "," + this.y.toString() + ") 
    scale (" + this.scale.toString() + ")");

I wanted to make use of the <use> element here as this is a great way to clone a group of SVG fragments. Unfortunately, the implementation of <use> varies across browsers, specifically in the case of styling and events.

Next I use the SVGDOM getBBox() method to grab the dimensions of the die as we shrink each one along the way. This method returns an SVGRect which is used in the physics engine to detect collision.

var rectSize = this.die1.getBBox(); // calculate dimensions for use with physics
this.height = rectSize.height;
this.width = rectSize.width;

One of my favorite parts of building this sample was the discovery and use of the Box2DJS engine which made physics a breeze! This engine is used in many projects and is now available to web developers. Before I create the dice, I actually initialize the world around me:

function createWorld(width, height) {
    var worldAABB = new b2AABB();

    var world = new b2World(worldAABB, gravity, doSleep);
    createGround(world, width, height);
    // Side
    createBox(world, 0, 0, 30, height);
    createBox(world, width, 0, 30, height);
    createBox(world, 0, 0, width + 30, 30);
    createBox(world, 0,height , width+30,30);

    return world;
}

And then during dice creation I add each die to the world and give it an initial velocity.

// add this dice to the physics engine
this.circleBody = createBall(world, this.xTrans, this.yTrans, this.width);    
// give the force a slightly random starting velocity
this.circleBody.SetLinearVelocity(initialForce);

After adding some user interaction to add dice, I remove dice and shake the cup. Then, I create a timer and step the world.

timer = window.setInterval(DoStuff, 16);
// move the world
world.Step(timeStep, iteration);

The Die class has a prototype update function that is called when the world steps. The primary mechanism for moving the dice is to get the coordinates from the physics engine and set the transform property with all of the elements originally established:

var transFormString = "translate(" + Math.round(this.circleBody.m_position.x)
     + "," + Math.round(this.circleBody.m_position.y) + ") scale (" +
     this.scale.toString() + ") rotate(" + Math.round(this.rotation).toString()
     + "," + Math.round(this.xTrans).toString() + "," +
     Math.round(this.yTrans).toString() + ")";

We now have moving, rolling, colliding dice.

Note that using the transform attribute is not necessarily the fastest approach, depending upon the implementation. As mentioned previously, I shied away from the SVGDOM which provides methods such as setTranslate() and setRotate(). The method I chose here considers potential future use of CSS Transforms with CSS Transitions and/or CSS Animations.

Styling the Graphics

Lastly, I wanted to take advantage of SVG integrated into the DOM and use CSS to change the style of the scene. Since the original art came from a design tool, it contained RGB values for colors and opacities.

<linearGradient id="cgrad2c" x1="1" x2=".17" y1="0" y2=".58">
    <stop stop-opacity=".9" offset="0"  stop-color="#700d0d"/>
    <stop stop-opacity=".9" offset="1" stop-color="#b51616"/>
</linearGradient>

I replaced these RGB values with styles:

<linearGradient id="cgrad2c" x1="1" x2=".17" y1="0" y2=".58">
    <stop class="diceCorner6"/>
    <stop class="diceCorner7">
</linearGradient>

This allowed me to create style sheets for each of these styles:

g#classHandler.vegas .diceCorner6 {stop-opacity:.9;offset:0;stop-color:#700d0d;}
g#classHandler.vegas .diceCorner6 {stop-opacity:.9;offset:1;stop-color:#b51616;}

g#classHandler.lowfidielity .diceCorner6 {offset:0;stop-color:#000000;}
g#classHandler.lowfidielity .diceCorner6 {offset:1;stop-color:#000000;}

And then set the one class property at the top of the document to change all of the styles in the document:

// set the overall stylesheet via class
document.getElementById("classHandler").setAttribute("class", style);

This allows the user to change the style sheet even while the dice are rolling as there is no difference to the DOM as to when these styles are changed. Hardware accelerated graphics in Internet Explorer 9 enable this to happen very quickly.

Call to Action

Start working with SVG in Internet Explorer 9. IE9 is platform complete for SVG in the latest platform preview release. Experiment with the feature set and tell us about incompatibilities or bugs you find using the “Report Issue” command and on Microsoft Connect.

The IE team is testing sites, libraries and other SVG content on the web. Our goal is to help authors with their content and find any bugs in our feature set. One important best practice is using feature detection, not browser detection when testing for SVG support. Help us find the places where developers are detecting specific browsers instead of testing for functionality, and make any changes to open source libraries, or contact content authors such that we can help fix any issues that may arise.

We’re excited to see web developers start using this technology and the next generation, graphically rich, websites built with SVG.

Patrick Dengler
Senior Program Manager
Internet Explorer

When we first showed IE9 at the Professional Developers Conference last fall, we discussed how real world browser performance involves many different subsystems. Different websites use these subsystems in different ways, and to build a fast real world browser you have to start by understanding these overall patterns. This post provides an inside look at how these subsystems impact the performance of five real world websites. We use Internet Explorer 8 for this analysis, and as IE9 approaches we’ll talk more about how these performance characteristics evolve.

All modern web browsers are conceptually similar. Browser vendors have different priorities (for example, supporting many different operating systems or optimizing for one). Browser vendors also have different engineering approaches which influence their programming languages, tools, and processes. When you step back from the specific engineering details though, all modern browsers connect to a server and execute the same markup and script. They all essentially do the same thing to enable customers to interact with web sites.

Browser Subsystems

The Internet Explorer web platform is composed of 11 core subsystems. All modern browsers provide these capabilities, and while the names and component boundaries vary slightly between browsers, the process is nearly identical.

Here’s a brief overview of these subsystems in the order they’re encountered when you load a web site:

Networking: The first subsystem generally encountered is networking. The networking subsystem is responsible for all communication between the client and server, including local caching of web content. The networking subsystem is generally gated on the performance of the user’s network

HTML: As HTML documents are downloaded from the server they’re passed to an HTML subsystem which parses the document, initiates additional downloads in the networking subsystem, and creates a structural representation of the document. Modern browsers also contain related subsystems which are used for XHTML, XML and SVG documents.

CSS: When CSS is encountered, whether that’s inside an HTML document or a CSS document, it’s passed to a CSS subsystem which parses the style information and creates a structural representation that can be referenced later.

Collections: HTML documents often contain metadata, for example the information described in the document head or the attributes applied to an element. The collections subsystem is responsible for storing and accessing this metadata.

JavaScript: When script is encountered, it’s passed directly to the JavaScript subsystem which is responsible for executing that script. The JavaScript subsystem is probably the most well-known of the browser subsystems thanks to the visibility it has received over the last few years.

Marshaling: Because most JavaScript engines are not directly integrated into the browser, there is a communication layer between the browser and the script engine. Passing information through this communication layer is generally referred to as marshaling.

Native OM: JavaScript interacts with the document through the Document Object Model API’s. These API’s are generally provided through a subsystem which knows how to access and manipulate the document and is the primary interaction point between the script engine and the browser.

Formatting: Once the document is constructed, the browser needs to apply the style information before it can be displayed to the user. The formatting subsystem takes the HTML document and applies styles.

Block Building: CSS is a block based layout system. After the document is styled, the next step is to construct the rectangular blocks that will be displayed to the user. This process determines things like the size of the blocks and is tightly integrated with the next stage - layout.

Layout: Now that the browser has styled the content and constructed the blocks, it can go through the process of laying out the content. The layout subsystem is responsible for this algorithmically complex process.

Rendering: The final stage of the process occurs inside the rendering subsystem where the final content is displayed to the user. This process is often referred to as “drawing to the screen” and may occur on the CPU, the GPU, or a combination of both.

As we’ve mentioned, different websites use these subsystems in different ways. Even websites that provide similar functionality, for example some of the world’s largest news websites which provide comparable experiences on their home pages including headlines and video, have very different performance characteristics.

Profiling News Sites

To help you understand what we mean, we took five of the world’s largest news websites and profiled them loading inside IE8 using the Windows Performance Tools. We do this in a controlled environment to remove external variables and we load each site multiple times to ensure high confidence with the results. We factor out networking performance from these charts because that’s user dependent. This approach allows us to see how long it takes the browser to load the web site and the breakdown of CPU time across subsystems. In the below chart, you can see that it took between 1,117 and 3,704 milliseconds to load these five pages - that’s between 1.1 and 3.7 seconds. The color coding represents the browser subsystem where the time was spent.

There are some revealing patterns in these results. For example, News Site #1 spent the majority of the time in JavaScript, News Site #2 spent the majority of the time in Marshaling, and News Site #5 spent the majority of time in the Layout process which includes Formatting and Block Building. For each website a different subsystem made the largest impact on performance.

It’s also interesting to see how much control the web developer has over their own site’s performance. Even though News Site #3 provided a comparable experience to their competitors, they follow performance best practices and the site is quickly loaded in just over a second. In contrast, News Site #4 doesn’t follow many best practices and takes over three times as long to load.

When we average these results together we can start to understand the relative impact each subsystem has across news sites. As you see below, every subsystem plays an important role in the performance of these News Sites with JavaScript (29%), Marshalling (18%) and Rendering (17%) making the largest impact.

Profiling Top AJAX Sites

News sites provide one view into how performance is multidimensional; however it’s important to look at other classes of web sites to see how these patterns change. When we perform the same analysis on the world’s top 25 AJAX sites, including some of the most sophisticated JavaScript applications like Facebook, Gmail and Hotmail, we get the following results.

As you can see the distribution has shifted slightly. Some subsystems including HTML, CSS and JavaScript become relatively less important and other subsystems including Formatting, Layout, Block Building and Rendering become extremely important. This can be surprising at first since most people associate AJAX sites with JavaScript. When you think about the patterns inside AJAX sites though, these results make sense. Inside most AJAX sites you generally have a small amount of JavaScript that manipulates the document. Once that script executes, the browser needs to go through almost all of the subsystems for that change to become visible to the user. That process is generally more expensive than executing the script itself.

You can see that performance of AJAX sites is also multi-dimensional and impacted by all of the subsystems in the browser. For AJAX sites, the most important subsystem is rendering which accounts for 31% of the time, followed by the JavaScript subsystem which accounts for 21% of the time. It’s interesting to see how JavaScript subsystem performance has proportionately more impact when loading a web page than when interacting with an AJAX site.

Bringing It All Together

To build a fast real world browser you have to understand how different browser subsystems impact performance in real world scenarios, and you have to focus on the subsystems that matter. For AJAX sites, that means focusing on Rendering (31%), JavaScript (21%), Formatting (14%) and Layout (12%). For news sites, that means focusing on JavaScript (29%), Marshalling (18%) and Rendering (17%).

With Internet Explorer 9, we worked on building the right foundation across the browser to ensure developers have a reliably fast platform. Over the last few months we’ve talked about some of the fundamental changes we made including hardware accelerated graphics, compiled JavaScript, and natively integrating JavaScript directly inside the browser. As we get closer to the IE9 beta we’ll talk more about how these subsystems come together in IE9 to change the performance characteristics compared to today’s generation of non-hardware accelerated browsers including IE8.

Jason Weber
Lead Program Manager, Internet Explorer Performance

The first IE9 Platform Preview unveiled IE9’s initial support of SVG. As explained previously, SVG is a vector image format managed by the W3C. The release of the third and fourth Platform Previews come with feature-complete SVG. Major additions include support for SVG gradients, patterns, clipping, and masking. These features are often used to create images with depth and texture and are typically found in more complex SVG files. Just like the rest of SVG in IE9, the newly added features are fully hardware accelerated. This results in impressive performance especially for computationally complex features such as clipping and masking. We continue to work with the SVG Working Group to resolve ambiguities in the SVG 1.1 2^nd edition specification and to ensure that IE9’s SVG implementation is interoperable.

9 Things I <3 About SVG

SVG’s benefits are multifaceted. It’s an incredibly flexible and powerful format that is ideal for a variety of use cases. Here are just a few of the reasons why SVG can play a critical part of the HTML5 web:

1. Scale-ability

An obvious benefit of SVG is scalability, as evidenced by the name Scalable Vector Graphics. This makes it an ideal format for maps, charts, and graphs – graphics where the detail is as important as the overall picture. With SVG, the fidelity of the graphic is maintained at all resolutions. A company logo or website icon can be created once and used many times in different places or sizes. The same image no longer needs to be saved at multiple resolutions, each tailored towards a specific purpose. Maps often need to be viewed as a whole in addition to being able to selectively see sections in detail. Currently, a common format for maps is a PDF file. This format makes it easy to to scale the map to different sizes,print at many resolutions with full fidelity, and provides the user with the ability to search within the document. SVG has all of these positive qualities natively supported; no plugins are required. Preset views of the same document can even be defined to make navigation to different sections simpler.

2. Script-ability

SVG is supported by a rich DOM, making it easy to script and manipulate SVG with Javascript. Because SVG shapes are graphic objects akin to HTML elements, SVG scripting uses common patterns that web developers already understand. SVG elements can take event handlers; they can be modified via the DOM or by the DOM L2 Core setAttribute() and getAttribute() methods. All attributes that describe the SVG element can be modified, from position to color to the shape of the element. The example below demonstrates how event handling and scripting can be used to create interactive SVG.

3. Style-ability

There are several ways to include SVG on a webpage. The <embed>, <object>, <iframe>, <img> tags can reference an SVG file. SVG can be included via CSS as a background-image or a list-style-image. To really integrate SVG with the page, it can be included inline in XHTML or HTML5. Standalone SVG documents and inline SVG have the advantage of being fully incorporated in the webpage. The SVG is treated just like other HTML elements and is styled with the same CSS block that styles the entire page. Websites – complete with icons, logos, navigation UI, and other SVG graphics – are skinnable with stylesheets alone. A print stylesheet can even be applied to your SVG images to allow more control over the appearance of the image on paper. Take a look at the example below. If you’re using a browser that supports SVG, you can switch between stylesheets to see how SVG images can change just by altering a simple stylesheet!

4. Search-ability

SVG is a format based on XML, so it’s composed of elements and attributes that are human-readable. Text in an SVG file shows up as text in markup. The XML format enables users to search the document for text, which is not possible in the more traditionally popular GIF and PNG image formats. For developers, the text-based format means that text in SVG images is surfaced to search engines. With this information, a website can be more comprehensively indexed and found by the right people. For example, a flow chart can be picked up by a search engine without requiring the web author to transcribe every panel of the chart.

5. Accessibility

In addition to the searchable aspect of SVG, another benefit of the text-based format is accessibility. Unlike raster images which can have a single, all-encompassing title text and description, the <title> and <description> elements can be applied to any SVG element. A web author can provide a description for each individual component in addition to the whole document, providing a more detailed description  while making it easier to understand. An SVG document has structure to it, which can enable a clearer understanding of it. Additionally, the “focusable” attribute can be added to make it easy to tab through select portions of the SVG.

6. Decorative Text

SVG is not restricted for use on graphically intense websites. It can be used throughout an HTML5 or XHTML file. It’s a terrific option for decorative text headers. SVG text can be styled in more ways than HTML text. Gradients and patterns can be used in SVG text. SVG text can also be stroked, unlike HTML text. Compared to raster images, SVG text is much more flexible for editing. Used in combination with a CSS block, text across many areas of the document can be given the same appearance, much like HTML headers today. And with IE9’s support for WOFF, you can even apply the same WOFF font used elsewhere on your page! SVG text can be rotated or laid out along a custom path. Overall, SVG text enables more flexibility and creativity in text on a webpage. Try the example below to see how easy it is to create decorative text!

7. Data-Driven/Server-Generated SVG

SVG is an XML specification, making it a good target format for server-generated images. Server-generated XML is fairly common; RSS and Atom feeds are a couple of examples. Maps, charts, and graphs often draw from a store of data. SVG is already a prime candidate for these types of documents. With the ease of XML generation, SVG really shines as a fantastic format for creation of these informational images.

8. Seamless Browsing Experience

One of SVG’s advantages over alternative 3rd party plug-ins (such as Flash or Silverlight) is native browser support which offers several benefits. To experience SVG on the web, users don’t need to install add-ons. Built-in support is convenient for the user and reduces exposure to potential add-on vulnerabilities. SVG is hardware accelerated in IE9, offering a smoother interactive and viewing experience for users. Additionally, SVG offers better integration with page markup, DOM, and script to provide for a consistent programming model and better user experiences.

In IE9, SVG is treated much like an image today and matches user expectations of an image: it can be saved into the PNG and BMP raster image formats; it can be copied and pasted into a Word document or Powerpoint presentation as a rasterized version -- much like PNGs, JPEGs, and GIFs found on the web today; it can be set as a desktop background; printing SVG is just like printing an image. The browser also takes advantage of the benefits of SVG: it can be saved in the SVG format; it can be copied and pasted into Inkscape for editing as SVG; SVG text is searchable. Native support for SVG makes it easier for users to have a consistent browsing experience.

9. Familiarity/View Source

Because SVG is an extension of XML, learning SVG is merely an adaptation of XML/HTML knowledge that many developers are already familiar with. Many of us learned HTML using a browser’s View Source feature with Web sites we admired. SVG works the same way: View Source on a SVG file or an HTML5 file with inline SVG, and you can see, learn, and understand how an SVG graphic was made. And SVG elements work with IE9’s  debugging tools. As such, SVG is a web technology that is easy to pick up.

Additionally, several commonly used tools – such as Visio or Adobe Illustrator – are already capable of outputting SVG files. Inkscape is another fantastic tool for creating SVG; it specifically targets SVG as an output format and is free to download.  Using SVG on the web is a natural transition.

Call to Action

If you plan to use SVG on your website, you may also want to provide fallback behavior for browsers that do not support SVG. Depending on the context, it may be appropriate to use text, an image, or a combination of both to supplant the SVG. Remember to use feature detection, not browser detection to determine which format to display. SVG has an assortment of feature strings to describe SVG support for different modules. Using a try-catch statement and the hasFeature() method, you can determine if SVG is supported by the browser. For example:

try {
	if (document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Structure", "1.1")) {
		// display SVG
	}
	else {
		//fallback behavior
	}
}
catch(e) {
	// fallback behavior
}

Alternatively, if you embed SVG on your page as separate .SVG files, you can use the take advantage of the <object> tag by placing your fallback behavior within as follows:

<object data="vectorPanda.svg" type="image/svg+xml"><img src="pandaFallbackImage.png"></object>

If you are already serving SVG in HTML5 pages on your website, make sure that your HTML5 pages have the proper doctype so the pages load in the desired Document Mode. With no DocType present, IE9 will render in Quirks Mode and your beautiful SVG content will not display. Including the HTML5 DocType is as simple as inserting <!DOCTYPE html> as the first line of your Web page’s markup.

If you’re serving SVG within XHTML or directly as SVG, ensure that your Web server is serving with the proper MIME types:
                XHTML = application/xhtml+xml
                SVG = image/svg+xml

Please try SVG in the Platform Preview and see how it can enhance your site! Let us know what cool ideas you come up with. We’d love to see them!

Jennifer Yu
Program Manager

How do we decide whether to implement a feature that isn’t included in a standards specification? Like all browser providers, we often have to make this decision. In this post, I’ll use some real-world JavaScript examples to illustrate some of the principles we use to deliver an interoperable browser when the standards specification isn’t enough.

In an ideal world, a standards specification is the complete story. A JavaScript implementation would just include everything in the ECMAScript specification and nothing more. We believe that specifications published by standards organizations such as Ecma International or the W3C are essential for interoperability among web browsers. Ideally, such specifications tell the browser implementers what features they need to provide and tell web developers what features they should be able to use.

In the real world of the web, things are not so clear-cut. Specifications are seldom perfect and sometimes they are intentionally incomplete or ambiguous. Having served as editor for the ES5 specification, I know that there are always issues that don’t get fully resolved. The result is that there are widely implemented and used features that are not defined by any standard specification. If you are trying to build a browser that runs the existing web you have to implement many features that are not defined by a standards specification.

What’s the Real Regular Expression Grammar?

We built Chakra by carefully following the ECMAScript 5 (ES5) specification including the grammar for regular expressions. But when we started testing on actual web sites we started seeing pages not work because of syntax errors on some regular expression literals. For example, we failed on regular expressions containing a right square bracket such as:

next = /]/.exec(buffer);

The reason was that the grammar for regular expressions in the ECMAScript standard includes ] in a list of characters that you cannot directly use as a match character. The specification says that /]/ is illegal and instead you need to say /\]/. It turns out that it is important that [ is restricted in this manner because otherwise it wouldn’t be possible to parse literals like /axyz[a-d]qwer/. However a lone ] that isn’t preceded by a [ really doesn’t present a parsing problem. But the standard still says that it is illegal.

In practice, all browsers accept regular expressions such as /]/ and web developers write them.

Consensus feature is a term we use to describe such features that are not part of any standard but which are universally implemented in an interoperable manner. In general, IE9 and any other new JavaScript implementation need to implement such consensus features in order to work with actual web content. The real challenge is identifying them, as they are not included in the standards specifications.

We recognize that we have to support these sorts of consensus features and we will also be working to make sure that they get included in future editions of the appropriate web standards. However, not all JavaScript extensions are universally or uniformly implemented.

Why Doesn’t IE9 have those _ _ methods?

ES5 includes support for getter/setter methods. Similar features have been available in some web browsers for many years. Over that period, browser developers experimented with various syntaxes and APIs for defining such methods. Prior to ES5, the most widely implemented API for defining getter/setter methods used two methods named __defineGetter__ and __defineSetter__. Surrounding method names with two underscore characters is a convention that some browser developers use to identify methods that are either experimental features or which access unique low level capabilities of a specific JavaScript implementation.

ECMA TC39 members agreed that getter/setter methods should be included in the ES5 specification because their value had been clearly demonstrated. However, TC39 also chose to design a new API for defining them and to not standardize the __defineXXX__ APIs.

Why did TC39 do this? Because of significant differences in the behaviors of the browsers that had provided that API. Standardizing on a common semantics for these methods would mean that some or perhaps all existing browser implementations would have to change to conform to the new semantics. That would probably break some applications that were written to work with those specific browsers.

Another reason was to maintain consistent naming conventions. No other built-in names in ECMAScript begin or end with underscore characters. The association of such names with experimental or an implementation specific feature is widely known and using that convention for a standardized feature would be both misleading and would dilute the utility of the convention for future experiments.

TC39 developed a new API based upon the Object.defineProperty method. This API not only supports defining getter/setter properties but also support other new capabilities of ES5. The __defineXXX__ methods were left out of the ES5 specification.

Browsers that already provide the __defineXXX__ API are free to continue to supporting them unchanged for compatibility reasons. However, new code that is written to be interoperable among browsers supporting the ES5 standard should use Object.defineProperty to define getter/setter properties.

We still get requests that we add the __defineXXX__ APIs to IE9. We understand why. Some developers already have code that uses those APIs and they would like that code run on IE9. However, we believe that supporting these APIs would not be in the best interests of the interoperable web. TC39 has already considered this API and concluded that it should not be standardized. If IE9 added support for the __defineXXX__ APIs, that action would move that API closer to being a permanent consensus feature of the web and would be essentially overriding the decision of TC39.

Unfortunately, in the short term this creates a small amount of additional work for developers currently using the legacy API. However, it is trivial to create a simple compatibility library for your code that implements the __defineXXX__ APIs in terms of Object.defineProperty.

A Malfunctioning Consensus Feature

Within JavaScript code, a function can be referenced and called in code that precedes the actual function declaration. This is possible because JavaScript logically “hoists” all function declarations to the top of the containing code body. JavaScript also allows more than one function declaration to exist for the same function name. Consider a simple test function:

function testFuncDeclarationOrder () {
   f1();
   function f1() {alert("first f1")}
   f1();
   function f1() {alert("second f1")}
   f1();
}

When called, this function produced the alert sequence: “second f1”, “second f1”,”second f1”. The reason is that JavaScript actually processes the function as if it had been written as:

function testFuncDeclarationOrder () {
   function f1() {alert("first f1")}
   function f1() {alert("second f1")}
   f1();
   f1();
   f1();
}

The ECMAScript specification has historically placed only one restriction upon the placement of function declaration. The ECMAScript standard does not include the ability to place a function declaration inside the body of a control structure statement. For example:

if (someCondition) {
   function f1() {alert("f1")}
}

The above code would produce a syntax error if parsed in according to the ECMAScript specification. However, if you try this in any browser, you will find that you do not get an error. Supporting function declarations anywhere a statement is permitted is a consensus feature of the web. If so, why wasn’t it included in ES5? Section 12 of the ES5 specification actually says something about this:

NOTE Several widely used implementations of ECMAScript are known to support the use of FunctionDeclaration as a Statement. However there are significant and irreconcilable variations among the implementations in the semantics applied to such FunctionDeclarations. Because of these irreconcilable difference, the use of a FunctionDeclaration as a Statement results in code that is not reliably portable among implementations. It is recommended that ECMAScript implementations either disallow this usage of FunctionDeclaration or issue a warning when such a usage is encountered. Future editions of ECMAScript may define alternative portable means for declaring functions in a Statement context.

What does this dense statement mean? Simply stated, the behavior across different browsers varied so widely that reconciling them was impractical.

So what does IE9 do? Does it disallow such statement level function declarations as recommended by ES5? No, it treats such declarations exactly like previous versions of IE.

Why did we make that decision? Because previous experiments by browser implementers found that rejecting such declarations broke many existing web pages.

This may seem surprising. How can a web page rely on features that behave different across browsers and still be interoperable among browsers? One possibility is that the code isn’t actually used. It may be in a function that is never called or whose result is not essential to the operation of the page. However, if the JavaScript implementation treated these functions as syntax errors the entire script would be rejected even though the code is never called.

We don’t like having to implement a feature that is such a hazard for developers. But its existence is enshrined in the web so we really had no choice.

So What About const?

We are sometimes asked whether we will support the const declaration in IE9. const is a non-standard JavaScript extension that provides a way to declare “named constant” values. A typical usage might be something like:

const pi=3.14159;

Several browsers support this feature but there are significant differences in their handling of unusual situations and in what they define to be errors. Here is an example that shows some of the differing behavior among the browsers that “support” const:

// a function with multiple const declaration for the same name
function f() {
   alert('executing within f');
   const x=1;  //declare constant x as 1
   alert(x);
   const x=2;  //redeclare constant x as 2
   alert(x);
   x=3;        //try to assign 3 to x
   alert(x);
}
alert('about to call f'); f();

Depending upon the browser, running this code it might:

• Issue a syntax error and not load the page.
• Throw an exception when f is called.
• Alert: '1', '2', '2'. This means conflicting const declarations are allowed but the assignment was ignored.
• Alert '1', '2', '3'. This means that const was treated just like var.

Basically, only very simple uses of the const declaration are interoperable among browsers that support the declaration. Many more elaborate uses, or scenarios that might trigger some error condition, are not interoperable among those browsers.

An actual JavaScript implementation can’t only support the trivial common use cases. A real implementation also has to do something for all the odd edge cases and error scenarios that exist on real web pages. Arguably, it’s mostly for situations like this that we have standardized specifications. It’s generally pretty obvious what should be done for the simple common use cases. It’s the edge cases that require a standards specification in order to have interoperable implementations.

TC39 seriously considered including const in ES5 and it was in early ES5 drafts. However, there were many issues about how it should be defined and how it interacts with other declarations. Ultimately, there was agreement within TC39 that standardization of const should wait for the “next” edition of the specification where perhaps some of these other problems could also be addressed. Basically, TC39 decided it did not want to standardize on a flawed feature. Instead, it chose to defer any standardization of const for a future where a single improved design could be incorporated into all browsers.

So, what is IE9 doing with const? So far, our decision has been to not support it. It isn’t yet a consensus feature as it has never been available on all browsers. There is no standard specification and there are significant semantic differences among all the existing browser implementation. In addition, we know that TC39 decided not to standardize any of the existing alternatives and wants to reconsider it in the next ECMAScript revisions.

We understand the desire of many web developers to have such a declaration. But we also don’t want to create another situation like conditional function declarations where the feature has to exist but web developers better not use it if they care about browser interoperability. In the end, it seems like the best long term solution for the web is to leave it out and to wait for standardization processes to run their course.

Principled Decision Making

These are just four JavaScript specific examples illustrating the sort of decisions we have to make in creating IE9. Many similar issues come up with regard to other web standards and consensus features. For each we perform a similar analysis. What does the standard say? How many websites actually require it? Is it a consensus feature with a common semantics? Are there multiple, incompatible variants of the feature? Is a standards committee working on it? Do any test suites exist? Would our adoption help or hinder the standards processes? In the end it is a judgment call, and we try hard to make principled consistent decisions.

Allen Wirfs-Brock
Microsoft JavaScript Language Architect

IE has traditionally drawn a 2-pixel border around the content area of a site. This border, drawn as part of the page rather than IE’s frame, affects calculations of distance from the top and left of the page. It also creates a not-so-modern beveled look.

In the fourth Platform Preview, you’ll notice pages running in IE9’s Standards Mode no longer have the border. Here’s a before and after:

Before

After

Pages that run in legacy document modes will still have a 2-pixel border so that any site calculations dependent on the 2 pixels remain the same as in IE8.

To make sure your site runs in IE9 Standards Mode and gets this and all the other latest features in IE9, use a strict doctype. We recommend the HTML5 doctype (<!DOCTYPE html>) since it’s simple and will put your site in Standards Mode in all current browsers.

John Hrvatin
Program Manager

Earlier this morning the W3C announced the formation of a new Web Performance Working Group chartered with making it easier to accurately measure web application performance. Enabling web developers to understand the real world performance characteristics of their applications is critical to the success of HTML5, and we’re excited to have been selected as co-chairs of the new working group alongside Google. We look forward to partnering with the W3C and the broader web community to enable these scenarios through an interoperable API.

The first deliverable for the working group is to recommend an API that measures the performance of browser navigations. The WebTimings specification provides a good starting point for these capabilities, so this specification will move into the Web Performance Working Group and become the foundation for our recommendations.

The third Internet Explorer 9 Platform Preview was the first browser to implement these portions of the WebTimings specification. Following standard conventions, we used a vendor prefix (ms) on the name because the specification was still under active development and hadn’t been brought into the charter of any working group. Google also recently provided an early implementation of these API’s inside Chrome using their vendor prefix (webkit). Through early collaboration between our engineering teams, we almost have interoperable implementations which is impressive for an API that has only been discussed for a few months. This is a great example of what’s possible through collaborative partnerships at the W3C.

With two early implementations available, it shouldn’t take long to finalize an interoperable API and remove the vendor prefixes. We can’t do this alone though - the new working group needs your feedback to ensure we have the right design. Over the next few weeks we’ll post more details on the working group website and begin to solicit feedback. In preparation, you can try out these API’s using the IE9 Platform Preview or Chrome 6 nightly builds. To help you get started take a look at the msPerformance demo on the IE9 TestDrive which shows these API’s in action.

Jason Weber
Lead Program Manager for IE Performance

IE9 introduces support for the CSS3 Color Module, including its popular opacity property. As we have done with other standards-based features, opacity is implemented so that the same markup used in other browsers just works in IE9’s ­standard mode.

Internet Explorer 8 and earlier versions implemented an alternative mechanism to apply opacity using the alpha filter of the IE-specific filter property. This creates a compatibility challenge because IE9’s standard mode supports only opacity and not the alpha filter. (IE9’s compatibility modes Quirks, 7, and 8 still support the alpha filter but do not implement opacity.)

For sites that use best practice feature detection, this is not a problem. They will detect that opacity is supported in IE9 and use it instead of filter. The problem is with sites that use browser detection and mistakenly assume that IE always uses filter alpha instead of opacity and then change only the filter property in script. The opacity effect will appear broken in those Web pages when run in IE9’s default 9 document mode. The fix is to detect the standards-based opacity feature first and browser-specific filter feature second as we’ve described in previous posts.

Example Best Practice CSS

.fiftyPercentOpaque
{
    opacity: 0.5;
    filter: alpha(opacity=50);
} 

Example Best Practice Code

// set flags for whether we should use opacity or filter with
// this browser (or browser mode). we prefer opacity.
var useOpacity =
   (typeof document.createElement("div").style.opacity != 'undefined');
var useFilter = !useOpacity
   && (typeof document.createElement("div").style.filter != 'undefined');

function setOpacity(el, value) {
   // let el be either an element object or an id string
   if (typeof el == 'string')
      el = document.getElementById(el);

   // ensure value is in [0-1] range
   value = Math.min(1, Math.max(value, 0));

   // set opacity or filter alpha depending on what's supported
   if (useOpacity)
      el.style.opacity = value;
   else if (useFilter)
      el.style.filter = "alpha(opacity=" + (value * 100) + ")";
}

Alternative Browser-detection Code

In general, we prefer feature detection to browser detection but we’ve see a lot of opacity-related code use browser detection instead of feature detection.  If you have a site that does that today, you may find it easier to update your browser detection so it works with IE9. Here’s code that properly detects when IE is running in a browser mode less than 9’s standards mode.

function browserDetectSetOpacity(el, value) {
   // let el be either an element object or an id string
   if (typeof el == 'string')
      el = document.getElementById(el);

   // ensure value is in [0-1] range
   value = Math.min(1, Math.max(value, 0));

   if (navigator.userAgent.match(/\bMSIE\b/)
         && (!document.documentMode || document.documentMode < 9))
      el.style.filter = "alpha(opacity=" + (value * 100) + ")";
   else
      el.style.opacity = value;
}

Summary

The problem described above occurs only when the opacity of an element is changed using script that doesn’t detect whether opacity is supported before changing filter. Sites that use only declarative CSS markup will continue to work fine even when opacity is changed indirectly by changing the CSS class of an element or using a pseudo-class such as :hover.

W3Schools offers a clear explanation of CSS opacity and IE’s legacy alpha filter.

—Ted Johnson, Program Manager Lead for Web Graphics

Recently, Google made available the “Google Analytics Opt-out Browser Add-on.” This add-on enables consumers to “indicate that information about the website visit should not be sent to Google Analytics.” We agree that making it easy for consumers to protect their privacy is good, and Internet Explorer offers a variety of features to help keep you in control of your information when visiting websites. In this post, we describe how to use some of these built in features to accomplish the same outcome without installing a Browser Helper Object and the Google Update Service.

Users of Internet Explorer 7 and 8 (and soon 9) who wish to prevent Google Analytics’ script from running can follow these steps:

1. In Internet Explorer, open the Tools menu and click Internet Options.
2. Click the Security tab and then click the Restricted Sites icon.
3. Click the Sites button.
4. In the box at the top, add *.google-analytics.com and push the Add button.
5. Click the Close button, and then the OK button to dismiss Internet Options.

After this configuration change, script from the Google Analytics website will not run on any webpage, and cookies will never be sent to the Google Analytics server.

How does this simple procedure work?  In IE7, we made a minor change to the Restricted Sites zone. IE will not run scripts that originate from sites the user places in the Restricted zone.

To protect your privacy further, IE will not send cookies to sites in the Restricted Sites zone.  In general, you can block script from any other domains by also adding those domains to the Restricted Sites zone.

Add-ons are useful and important. They are also a key cause of performance, stability, and security issues for all browsers. A more trustworthy approach involves building more functionality into the core browser and relying more on data (in the form of declarative descriptions, like XML) than code to extend the browser. For example, Accelerators in IE are XML descriptions of how to get a map, rather than arbitrary script that can get a map and possibly do more (like slow down the browser, or share more information than you’d like). Webslices are XML descriptions of parts of a webpage to show on IE’s Favorites Bar, rather than arbitrary script that can modify IE’s user interface and possibly do more than that under the hood.

In this situation, rather than install and run a lot of additional software on the machine, people can just add a web site to the Restricted Sites zone. Similarly, InPrivate Filtering in IE8 (and IE9) supports Importing and Exporting lists of sites that the user doesn’t want to exchange information with. That’s a simpler, safer, faster and more reliable approach than running more code.

Eric Lawrence
Program Manager

We’ve blogged in the past about guidelines and requirements that we’ve published to help add-on developers create quality add-ons.  We wrote these guidelines based on years of providing support to users and developers in response to questions from the developer community.

We’ve shared several great examples of these guidelines and requirements in action in the past few months. As part of IE’s cumulative security updates, we’ve released an update to the Internet Explorer Upgrade Advisor list that helps users update to new versions of add-ons that follow the guidelines and requirements. In this post, we highlight the latest add-ons that have made changes based on the guidelines and requirements, and we describe the Upgrade Advisor user experience in detail.

It’s been encouraging to see more add-ons recently release new versions with improvements in functionality based on these guidelines and requirements. As more developers follow them, our users will have a better experience. Here are some of the add-ons that have made changes to their functionality:

It’s important to update users to the new versions of these add-ons so they can benefit from improved stability and compatibility. Today we released an updated Upgrade Advisor list with IE’s Cumulative Security Updates to help users do just that. Users who have specific versions of the above add-ons may see the Upgrade Advisor dialog box when they launch Internet Explorer 8:

The dialog box presents the user with three options to choose from:

Option 1: Check online for an update
When the user selects this option or closes the dialog without making a choice, the dialog box is dismissed and a web page is displayed in a new window that runs in No Add-ons Mode. The user can follow the steps in this web page to install the new version of the add-on. If a link to the new version of the add-on is not provided by the vendor, or the new version does not follow the guidelines and requirements, the web page will inform the user that no update is available yet.

Option 2: Always open Internet Explorer without this add-on
When the user selects this option, Internet Explorer disables the add-on, the dialog box is dismissed, and Internet Explorer continues to launch.

Option 3: Keep using this add-on anyway
When the user selects this option, the dialog box is dismissed and Internet Explorer continues to launch with the add-on enabled until the next refresh of the Upgrade Advisor list which occurs approximately every 8 weeks.

Many thanks to the teams that have made changes to follow the guidelines and requirements. We will continue to work with add-on vendors to help them release new versions of add-ons that have better stability, compatibility and performance.

Herman Ng
Program Manager

The IE Cumulative Security Update for August 2010 is now available via Windows Update. This security update resolves six privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

This security update is rated Critical for Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. The security update addresses the vulnerabilities by modifying the way that Internet Explorer enforces security checks and handles objects in memory. For more information about the vulnerabilities, please see the full bulletin.

The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.

Tyson Storey
Program Manager

IE9 started from the premise that the modern web will deliver HTML5 experiences that feel more like native applications than sites. Building on hardware-accelerated SVG, canvas, video, audio, and text, developers will use the power of the whole PC to achieve great performance. On the modern web, developers will use the same markup across different HTML5 browsers.

With IE9, we have worked much more closely with the developer community. Developers have had an earlier (and more frequently updated) look at the platform. With that early engagement, developer feedback has had a bigger impact than before. People have downloaded IE9 Platform Previews over 2.5 million times. The samples on the IE Test Drive site have had over 20 million visitors. We appreciate the positive feedback and all the specific issues logged in Connect. They’ve helped us make demonstrable improvements that the community has noticed.

The fourth Platform Preview of Internet Explorer 9, available now, shows the opportunity of fully hardware-accelerated HTML5. You can run new test drive samples that show modern SVG and native JavaScript integration in action. In March, we promised to deliver platform preview releases approximately every eight weeks. With this installment, you will find more performance and more support for same markup. You’ll also find many fixes to issues reported in previous Platform Previews. Here is a video of some of the test drive samples:

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.

Fully Hardware-Accelerated HTML5

The performance benefits of hardware acceleration are clear from running different sample sites side by side in IE9 and other browsers. Browsers that implement partial hardware acceleration – for example, text-only, or video-playback only, or image-only acceleration – offer inconsistent and possibly unpredictable platform experiences to developers and end-users.

IE9 offers consistent, fully hardware-accelerated text, graphics, and media, both audio and video. Try Hamster Dance Revolution, IE Beatz, or MSNBC Video in different browsers to experience the difference. Psychedelic Browsing demonstrates what HTML5 canvas can do when it’s fully accelerated with the GPU.

Modern SVG

With Platform Preview 4, we’re excited to show highly-interactive and integrated, or modern, SVG. Typically, developers think of SVG as the graphics format for static engineering diagrams and images. With HTML5 and hardware acceleration, SVG is an excellent choice for a new class of interactive, animated scenarios.

You can see great SVG performance, animated via JavaScript, with the SVG Dice example. The sample shows striking performance differences between browsers animating the same SVG markup, as well as the benefits of being able to style SVG with CSS. Unfortunately, you can see differences in how different browsers display the same SVG; as an industry we have more work to do so the same markup delivers the same results.

Native JavaScript Integration

We’re committed to the right foundation for HTML5 applications, including performance and ensuring the same markup and same script work across browsers. One aspect of doing these things well is integrating the JavaScript engine natively inside the browser, rather than bolting it onto the side to support multiple JavaScript engines as some other browsers do today. How a JavaScript engine is integrated into the browser is as important as the engine itself for real-world HTML5.

The fourth Platform Preview moves the new JavaScript engine, codenamed Chakra, inside IE9 and brings them together into one single, integrated system.

Through this deep integration, the performance of real world websites significantly improves, and IE9 becomes the first browser to have a shared DOM between the browser and the script engine based on ECMAScript5. The benefits start with real-world performance and consistency.

The easiest way to understand the importance of this fundamental change is by looking at how earlier versions of Internet Explorer integrated JavaScript. For the last 15 years Internet Explorer has supported multiple programming languages including JScript, VBScript, and even specialized languages such as Perl. While this gave developers choice it also came at the cost of performance and features. The browser and these script engines communicated through COM which could cause performance problems. Each script engine had its own language specific view of the DOM which created discrepancies. Additionally, the browser was forced to use a least common denominator approach which made adding new features challenging.

In the fourth Platform Preview, we’ve moved the JavaScript engine inside IE9. With this change, communication between the browser and script engine is now direct, which significantly improves performance for real world websites. We now have a single DOM, shared across all browser subsystems including JavaScript. This change ensures a consistent and interoperable view of the document. And this single DOM is now based on ES5, which prepares the entire system for the future.

When programming the IE9 DOM from JavaScript, objects now feel like native ES5 objects because, underneath the covers, they actually are ES5 objects. This approach brings the benefits of ECMAScript5 to the DOM. With the fourth Platform Preview, IE9 becomes the first browser to have a fully discoverable DOM through ES5 reflection features. IE9 is the first browser to apply ES5 bindings to DOM objects, enabling a full Inheritance view of the DOM, and taking advantage of the WebIDL specification as the foundation for this support. Together, these changes provide developers a natural ES5 based programming model. Try some of these enhanced DOM capabilities out for yourself to see how well your browser’s DOM and JavaScript engine are integrated. IE9 will continue to support additional programming languages through the legacy model, but we strongly encourage developers and enterprises to take full advantage of the benefits of JavaScript moving forward.

Platform Preview 4 also continues improvements to the JavaScript engine itself. One measure of JavaScript performance is the Webkit Sunspider microbenchmark. Here is a chart of the latest results:

The differences between browsers on this microbenchmark are converging within thousandths of seconds on tests that repeat operations many, many times to find any differences at all.

Real-world HTML5 performance often reflects the entire browser’s performance, not just the JavaScript engine in isolation. This video, for example, shows a side by side comparison of different browsers running an HTML5 canvas. The performance differences between browsers are striking and do not reflect relative JavaScript performance. We encourage other browser vendors to consider following our lead in designing for end-to-end performance and natively integrating JavaScript engines rather than treating script as a separable subsystem to be optimized in isolation.

Same Markup, and Tests

To assess the quality and completeness of a browser’s standards support, we look to the official standards bodies. Their open, consensus-based process is the best way to bring the community of browser vendors and web developer and design professionals together in building a test suite.

With Platform Preview 4, we’re contributing 519 new tests to the standards bodies. Based on community feedback, we’ve also updated five of the previously submitted tests. This brings the total number of tests we’ve contributed during IE9 development to 2,138. We welcome your feedback on the specific test cases. Please continue to provide feedback on the test cases to the appropriate W3C working group. In case of ES5 test cases please provide test case specific feedback via Microsoft Connect. We also invite you to submit your own test cases to the standards bodies as well. You can find the test cases Microsoft has developed at the IE Test Center.

These test cases represent a strong start on a complete and comprehensive test suite of the web standards developers expect to work consistently across browsers. While the suite is not complete yet, it is interesting to note how interoperable some of the same markup is across different browsers:

Some people use a particular test or website as shorthand for standards compliance. Different sites test different subsets of different standards to different depths. Acid3 is one that some people in the community have cited. It tests about 100 fragments of a dozen different technologies. Here’s a screenshot of how today’s IE9 Platform Preview runs today’s Acid3 test, going from 83 in the previous platform preview to 95:

As IE9 has implemented more of the standards that developers use and value, IE9’s Acid3 score has continued to rise. The remaining points involve two particular technologies (SVG Fonts and SMIL animation of SVG) that are in transition.

Support for SVG Fonts in the web development and font communities has been declining for some time. There’s already been discussion without objection of dropping SVG fonts from the Acid3 test. The community has put forth a proposal in the SVG Working Group to give SVG Fonts optional status.

Instead, developers can use the Web Open Font Format (WOFF, supported in IE9 Platform Preview 3 as well as other browsers) for both HTML and SVG content. It works well in conjunction with the CSS3 Fonts module and has broad support from leading font vendors (e.g. here, “a majority of font makers have already settled on WOFF or services like Typekit as their format of choice”). WOFF fonts are a better long-term solution for many reasons discussed previously.

Similarly, support for SMIL animation of SVG in the web development community is far from strong. The leader of the SVG standardization effort wrote that not supporting SMIL in its current state is probably best “since the SVG WG intends to coordinate with the CSS WG to make some changes to animation and to extend filters.” There’s already work started to reconcile CSS3 animations and SVG. Developers interested in animating SVG can use JavaScript, as the samples in the test drive site do today, with consistent results.

Getting sites ready for Beta

With the fourth Platform Preview, we strongly recommend developers, designers, and partners to start getting your sites ready for the IE9 Beta.

• Test your site in IE9 Standards Mode.  This mode provides the best performance and interoperability and will offer additional benefits in the IE9 Beta. We suggest using the HTML5 doctype. More details here and here.
• We recommend sending IE9 the same standards-based markup your site sends other browsers. More details here and here. From the feedback so far, and our experience with sites, the best way to get your site working in IE9 Standards Mode is to start from the same markup other browsers receive rather than IE6, IE7, or IE8 markup.
• Use feature detection, not browser detection to handle any cross browser differences in behavior or feature support.  This keeps your site working even as browsers change.
• Please continue to report issues on Connect if your site doesn’t look or work right, and you’re giving it the same code as you’re giving to other modern browsers. With IE9 Platform Preview 4, we’ve fixed over 100 community-reported issues. We will fix even more between now and the IE9 beta and want your feedback.
• Consider the experience for IE9 Beta users if you find that sending the same markup creates more issues than you can resolve in your production site. It is possible that running your site in Compatibility View is better for your users.
• Take advantage of HTML5, CSS3, SVG, DOM, ES5, and more… all described here in the developer guide.  We’re excited to run the amazing experiences you bring to the web using these new capabilities, taking advantage of hardware through IE9.

Platform Preview 4 is an important milestone on the way to beta. It is the last preview before the IE9 Beta. The IE9 platform is nearly complete. We ask that developers and partners start testing in preparation for the beta and prepare their sites to take advantage of IE9’s new capabilities. We continue to welcome your feedback via Connect.

Thanks,
Dean Hachamovitch
General Manager, Internet Explorer

In previous posts, we’ve written about the ways we’re making IE9 much faster, like the new script engine that uses multiple cores, and the new rendering subsystem that uses the dedicated graphics chip found on modern PCs. Another aspect of browser performance involves the external code that IE runs on behalf of users, or add-ons.

Add-ons introduce unique features that can enhance the browsing experience. However, they also decrease the browser’s performance in crucial activities like navigating to webpages and creating new tabs. In this way, add-ons affect key usage scenarios like startup and navigation.

Add-on performance is integral to an overall fast browsing experience. IE users expect the browser to be fast, with or without add-ons. We work towards several common goals with add-on developers: providing valuable features with the smallest performance and reliability impact possible (more on reliability in another post).

This blog post is the first in a series on how add-on developers can improve add-on performance. In this post, we’ll share data on the performance impact of add-ons today and how IE enables users to identify the performance impact of their add-ons and stay in control of their PCs. We’ll describe the user scenarios that are important for measuring performance and will walk through how to measure them.

We want add-on developers to have all the information they need to deliver fast, reliable add-ons that respect user choices. We want to make it clear how to test add-on performance. We ask add-on developers to start measuring add-on performance today and making their add-ons faster.

What is An Add-on?

Add-ons refer to Toolbars, Explorer Bars and Browser Helper Objects today. When add-ons are enabled in the browser, they can cause a performance impact for every tab opened and every webpage the user visits.

Another common type of extension is plug-ins, specifically ActiveX controls, like Adobe Flash, Apple QuickTime, and Microsoft Silverlight. Unlike add-ons that run in the browser across all web-pages, plug-ins run inside webpages and their performance impact is localized to the webpages that use them. The specifics of this post are about add-ons. Plug-in developers have similar opportunities to make the browsing experience faster and more reliable.

Accelerators, Webslices and Search Providers are a third class of extension. These are written in pure XML format, and were designed to not impact page or browser performance, reliability, or security.

Toolbar Buttons are another type of extension but they only impact IE’s performance when users press them and they’re mapped to an action that launches an add-on.

Understanding Add-on Performance Impact

Several studies regarding website response time report that users notice any delay over 0.2 seconds. Actions that are faster than 0.2 seconds appear instantaneous.  Scenarios with response times slower than that threshold can feel “slow” to users.

Tab creation is one such scenario. IE initializes add-ons every time the user creates a new tab to make sure that the add-ons can interact with a webpage properly (like the Skype IE add-on, which identifies phone numbers and makes them “clickable”). When the user starts a new instance of IE, one of the first things IE does is create a new tab that, in turn, initializes all the user’s add-ons. The time it takes each add-on to initialize is its load time, and usually depends on the amount of code the add-on executes during its initialization routine.

According to our telemetry data, over 95% of IE8 users today have at least one add-on installed, and users have an average of 9 add-ons installed. If a user’s add-ons each take more than 20 milliseconds to load, his new tabs will take a noticeably longer time to create than usual.

The following chart shows the median load times for the newest versions of the 50 most used add-ons in IE today. Users who have many of these add-ons installed will definitely notice a performance impact when starting IE or creating a new tab:

These are just the 50 most popular add-ons. Many add-ons that aren’t listed above may also have a performance impact on tab creation. We recommend users to install the newest versions of add-ons as they generally have the best performance.

End-users and Add-on Load Times

What’s important to an individual user is his or her own experience, not the broad ecosystem data. In IE8, we introduced a feature to enable users to see for themselves how their add-ons affect their browser performance.

IE measures the load time for each enabled add-on every time IE initializes it. In the Manage Add-ons dialog, IE displays the average load time for each add-on based on the last 10 initializations. You can access the Manage Add-ons dialog via the Tools Menu.

With this information handy, users can choose the add-ons they want to keep enabled, and maintain control over their browsing performance:

Add-on Developers and Add-on Load Times

We collected telemetry data on the load times across the add-ons that IE users have installed to evaluate their performance characteristics. The following chart shows the distribution of all add-on load times experienced by all IE8 users:

Even though most of the time add-ons load in less than 100 milliseconds, add-ons take longer than 200 milliseconds to load over 25% of the time. Users will perceive a noticeable impact on performance in these situations, more so if several of their add-ons have long load times. Measuring your add-on’s performance allows you to identify how often these long load times occur.

Let’s look at some specific examples of slower add-ons from our measurements, and some of the reasons these add-ons have such a large effect on IE’s performance during tab creation. If you are an add-on developer and would like to receive the following load time data for your add-on, you can email us at ieaddonp@microsoft.com.

Sample Add-on #1

Users with this add-on enabled typically see noticeable delays during tab creation. The majority of load times for this add-on are greater than 200 milliseconds.  The amplitude of the curve is higher than that of the previous chart. Further investigation revealed that this add-on is generally running more code than is minimally required during initialization.

Sample Add-on #2

This add-on also incurs an impact on the user’s tab creation performance as evidenced by the majority of load times that take over 200 milliseconds. We found that the add-on is performing operations that take a consistent amount of time to complete across all machines (600-1500 milliseconds). We recommend moving these operations off of the initialization routine to expedite tab creation.

Sample Add-on #3

Even though the distribution of load times for this add-on is different from the others, it also incurs an impact on tab creation performance. We investigated the cause behind the uniform distribution of load times beyond 100 milliseconds and found that the add-on is making network calls during initialization. Since network calls take a variable time to complete depending on the connection speed and locale, add-ons must refrain from making network calls during initialization. We recommend spinning off background threads to make these calls at a later time instead.

It’s clear that some IE8 users experience significant performance problems with add-ons during tab creation. Add-on developers who improve add-on load time take an important step towards improving IE performance for end-users. At the same time, we know that add-on performance extends beyond tab creation. Let’s look at the other scenarios in more detail.

Recommendations to Add-on Developers around Performance

In this post, we focus on understanding and measuring scenarios in terms of the elapsed time with the add-on enabled. There are additional metrics that are also important, such as CPU time (amount of time the CPU spent to complete the scenario) and working set (amount of memory required to run the scenario). We’ll cover these two metrics in a future post.

Tab creation and webpage navigation are two of the most relevant scenarios for IE performance. Add-ons have a large impact on the performance of these scenarios because they can block IE from completing the user task. Depending on how the developer wrote the add-on, IE may have to wait for the add-ons to finish running code before IE can finish creating the tab or navigating to the web page.

We recommend add-on developers start by measuring add-on performance in these two scenarios:

1. Tab Creation, Switching, and Closing
Some add-ons call across the network during tab create (which causes users to wait), or choose to save their state (with registry reads and writes) as the user is closing a tab, or to repaint their UI as the user is switching between tabs.

Because add-ons can interrupt IE as it handles the user’s request to create a tab, switch between tabs, or close a tab, add-ons can make these operations far from instantaneous.

2. Webpage Navigation
As the user navigates to a webpage, Internet Explorer fires a set of browser events. Add-ons can choose to run code in response to these events. Add-ons that handle one or more of these events can delay users from finishing the web page navigation. The impact is profound on webpages that users expect to open immediately, such as search results or stock market tickers. Some examples:

• BeforeNavigate: A security add-on inspects the destination URL before allowing the navigation to proceed.
• DocumentComplete: Once a webpage finishes loading, an add-on searches through the entirety of every webpage to add a button next to all the email addresses in order to launch a custom mail application
• NavigateError: If an error occurs during webpage navigation, the add-on redirects the user to a custom error page.

Given how important performance is for users, transparency and control of add-ons will also be important to them.

We also recommend that add-on developers measure and optimize their add-on performance using the publicly available Windows Performance Tools.

Specifics about Measuring Add-on Performance with Windows Performance Tools

We’ve recently blogged about how to measure browser performance with the Windows Performance Tools. Add-on developers can use these tools to measure various performance characteristics of the browser with their add-on(s) enabled. Here are the steps you can take to measure the tab creation and tab close scenarios for an add-on with the Windows Performance Tools installed.

1. Start an elevated command prompt and execute the following command to start a performance trace and log the results to a file (such as AddonTrace.etl):
   xperf -start browselog -on Microsoft-IEFRAME -f AddonTrace.etl
2. Make sure that your add-on is enabled.
3. Launch Internet Explorer to your home page. Wait several seconds after the navigation completes, and then open several new tabs.
4. Close each tab in order until the browser window shuts down.
5. Stop the trace by executing:
   xperf -stop browselog
6. Convert the contents of the .etl file into a text file that you can parse and measure for:
   xperf -i AddonTrace.etl -o AddonTrace.txt

Next, inspect the text file to find the following pairs of ETW events that correspond to the scenarios. To find the elapsed time for the event, subtract the timestamp of the end event from that of the start event:

In addition, you can use the Windows Performance Tools to measure add-on performance in the other scenarios we described earlier. Here are the ETW events that correspond to the other scenarios:

We recommend running these tests on a fixed environment against a set of the most popular websites to realistically measure performance. Caching these sites on a proxy server helps minimize variance in the website content. We also recommend running these tests across multiple machine configurations.

Add-on Performance: We’re all in, together

Performance is important to end-users: they’re paying attention and will take action to get better performance.

We encourage users to look at the performance impact of the various add-ons installed on their machines using the IE8 Manage Add-ons dialog. This information helps users stay in control of their browsing performance while using the add-ons they want.

We also encourage add-on developers to make those decisions easier for end-users by writing faster add-ons. We recommend developers start by measuring add-on performance using the Windows Performance Tools and follow the guidance we’ve included with this post. Set up a performance lab infrastructure with a server of cached websites and multiple machine configurations. While the IE8 add-on load time measurements serve as a gauge for end users, we recommend measuring performance across all the tabbed browsing and webpage navigation scenarios as well.

Using these measurements and our guidance above, you can tune your add-on for the best performance. As you find optimizations or best practices, we encourage you to share them with the developer community blog post comments here or on Connect.

Improving add-on performance is critical to building a fast and highly compelling browsing experience and we’re all in it together. We want IE users to enjoy great add-on functionality and great performance.

Herman Ng
Program Manager

Online privacy and tracking have been in several news articles and public hearings lately. The recent attention has been on how visiting one site shares information with many sites, and how those sites can then share the information and effectively ‘track’ your activity on the web. The articles certainly show the complexity of the topic. This blog post offers some context on online safety and privacy and specific information about InPrivate Filtering, a feature in IE8 designed to help protect users from some tracking scenarios, as well as several other features IE8 offers users to help protect their privacy online.

Part of what makes online privacy tricky is that browsing the web is fundamentally an information exchange. Your web browser offers information in order to get information. That information can identify you. Often, that information is sent automatically for your convenience (like the languages you prefer to read) to tailor the content for you.

Because some of the technologies that can be used for tracking are also essential today for basic functionality, there is no “Just give me perfect privacy” feature. The way different tracking and anti-tracking technologies interact can read like a Spy vs. Spy comic strip. Distinguishing between a tracking technology (a beacon) and a useful piece of web content (a stock chart used as a beacon) is not obvious. Some people are concerned about Adobe Flash’s “super cookies”; IE8’s InPrivate browsing clears these as well with newer versions of Flash.  As another example, InPrivate Browsing in IE8 “clears your tracks” and removes information from browser history when you close IE. During the actual browsing session, before you close it, IE still records history (so the back button continues to work) and cookies (so that logins and shopping carts continue to work). Ultimately, people want the web to work and privacy protection.

We designed InPrivate Filtering to help users control who can get information about their browsing. IE enables users to choose how privately they want to browse. Users are in control of several privacy protection features in IE, and how automatically they function. Specifically, users can keep browsing information from going to sites they don’t actually visit directly. IE determines the potential tracking sites on the list based on the sites you browse to directly and how those sites were written. Different sites on the web have articles about more advanced features, like always browsing with InPrivate Filtering on, and importing and exporting InPrivate Filtering lists.

People who are concerned with tracking may be interested in how to use InPrivate Filtering in IE. (People interested in how it works can read more here and here.)

1. From the Safety menu, choose “InPrivate Filtering.”

2. Choose “Block for me” to turn on automatic filtering.

Alternatively, you can choose “InPrivate Filtering Settings” from the Safety menu at any time to see a list of sites that are in position to track your browsing based on the sites you browse to in IE. You can find more detailed instructions in several places around the web with some basic web searches.

The sheer complexity of privacy and online safety spans many disciplines. We’ve posted here about different aspects of web browsing safety. Bad things can happen to good people on the web in many ways. Internet Explorer includes protections for many different kinds of threats people face on the web. People often focus on malicious sites that exploit unpatched security issues in different devices and software. (Microsoft regularly releases updates; please turn on automatic updating if you haven’t already.) Sites host seemingly good downloads (“Free Emoticons! Puppy screensaver!”) that are actually malicious, or attempt to lure people to visit them; users often download them and run them anyway. Otherwise “good” sites unintentionally host malicious content. Phishing sites pretend to be one site (perhaps your bank) but are actually malicious in their use of information. IE’s SmartScreen has protected users over a billion times by blocking these kinds of attacks. Protecting children online is another set of challenges entirely. Some kinds of trust violations that are lower in severity go unhindered. Browser add-ons can leak information across sites, even though add-on developers can prevent it. Protecting a user’s online privacy is just as important to Microsoft as protecting the user from malicious sites.

The web today has lots of great innovation. Unfortunately, threats to online safety and privacy also see rapid innovation. The communities working together to combat online safety issues span the technology industry, financial and commercial institutions, academia, government, and law enforcement agencies.

Dean Hachamovitch

List of articles referenced
Adobe Flash Now Supports InPrivate Browsing - IEBlog - Site Home - MSDN Blogs
Browser Information
Even without cookies, a browser leaves a trail of crumbs
Hearings - U.S. Senate Committee on Commerce, Science, & Transportation
How a browser extension leaks Google history to Amazon | CNET to the Rescue - CNET Blogs
How to Start Internet Explorer 8 in InPrivate Browsing Mode by Default - The Winhelponline Blog
HTTP/1.1: Header Field Definitions
IE June Security Update Now Available - IEBlog - Site Home - MSDN Blogs
IE8 and Privacy - IEBlog - Site Home - MSDN Blogs
IE8 and Trustworthy Browsing - IEBlog - Site Home - MSDN Blogs
IE8 Blocked over 1 Billion Malware Attacks | Windows 7 News
Protect Yourself from Malicious Advertisements with Internet Explorer 8
IE8 Security Part I: DEP/NX Memory Protection - IEBlog - Site Home - MSDN Blogs
IE8 Security Part II: ActiveX Improvements - IEBlog - Site Home - MSDN Blogs
IE8 Security Part III: SmartScreen® Filter - IEBlog - Site Home - MSDN Blogs
IE8 Security Part IV: The XSS Filter - IEBlog - Site Home - MSDN Blogs
IE8 Security Part V: Comprehensive Protection - IEBlog - Site Home - MSDN Blogs
IE8 Security Part VI: Beta 2 Update - IEBlog - Site Home - MSDN Blogs
IE8 Security Part VII: ClickJacking Defenses - IEBlog - Site Home - MSDN Blogs
IE8 Security Part VIII: SmartScreen Filter Release Candidate Update - IEBlog - Site Home - MSDN Blogs
IE8 Security Part IX - Anti-Malware protection with IE8’s SmartScreen Filter - IEBlog - Site Home - MSDN Blogs
IE8 SmartScreen in action - IEBlog - Site Home - MSDN Blogs
IE8: Ad blocking with the InPrivate Filter - SuperSite Blog
Internet Explorer 8 - InPrivate Filtering
Internet Explorer 8: Nine Things You Didn't Know You Could Do - IE8 Tips 5-9 | PCMag.com
Is Google Watching You? New Plugin Will Let You Know [APPS]
Linux infection proves Windows malware monopoly is over; Gentoo ships backdoor? [updated] | ZDNet
My Browser Info
Panopticlick (Electronic Frontier Foundation)
Privacy Beyond Blocking Cookies: Bringing Awareness to Third-Party Content - IEBlog - Site Home - MSDN Blogs
Privacy, Add-ons, and Cookie-less HTTP Requests - IEBlog - Site Home - MSDN Blogs
Rickrolling - Wikipedia, the free encyclopedia
Spy vs. Spy - Wikipedia, the free encyclopedia
What is Private Filtering on IE8 and How to Prevent Web Sites from Collecting Information About You?
Windows Live Family Safety
Your Privacy Online - What They Know - WSJ.com

The latest Platform Preview Build includes two great interoperable features for working with the DOM – DOM Traversal and Element Traversal. These features provide web developers with simple, flexible, and fast ways of traversing through a document using the same markup across browsers. These features come in the form of flat enumeration, simplifying the DOM tree to an iterative list, and filtering which enables you to tailor the set of nodes you traverse. These features work with the same markup across browsers – you can try out any of the code here in the IE9 platform preview and other browsers.

Without these features, finding an element of interest on a page requires you to do one or more depth-first traversals of the document using firstChild and nextSibling. This is usually accomplished with complex code that runs slowly. With the DOM and Element Traversal features, there are new and better ways of solving the problem. This blog post is a primer and provides a few best practices to get you on your way.

I’ll start with Element Traversal, since it’s the simplest of the interfaces and follows familiar patterns for enumerating elements in the DOM. Element Traversal is essentially a version of DOM Core optimized for Elements . Instead of calling firstChild and nextSibling, you call firstElementChild and nextElementSibling. For example:

if (elm.firstElementChild)
{
    elm = elm.firstElementChild;
    
    while (elm.nextElementSibling)
    {
        // Do work...
    }
}

This is faster and more convenient, saving you the trouble of having to check for text and comment nodes when you’re really only interested in elements.

DOM Traversal is designed for much broader use cases. First, you create a NodeIterator or a TreeWalker. Then you can use one of the iteration methods to traverse the tree:

var iter = document.createNodeIterator(elm, NodeFilter.SHOW_ELEMENT, null, false); // This would work fine with createTreeWalker, as well

var node = iter.nextNode();
while (node = iter.nextNode())
{
    node.style.display = "none";
}

The codepath above iterates through a flat list of all nodes in the tree. This can be incredibly useful since in many cases you don’t care whether something is a child or sibling of something else, just whether it occurs before or after your current position in the document.

A big benefit of DOM Traversal is that it introduces the idea of filtering, so that you only traverse the nodes you care about. While nodeIterator only performs flat iterations, TreeWalker has some additional methods, like firstChild(), that let you see as much or as little of the tree structure as you want.

The SHOW_* family of constants provides a way to include broad classes of nodes, such as text or elements (like SHOW_ELEMENT in the earlier example). In many cases, this will be enough. But when you need the most precise control, you can write your own filter via the NodeFilter interface. The NodeFilter interface uses a callback function to filter each node, as in the following example:

var iter = document.createNodeIterator(elm, NodeFilter.SHOW_ALL, keywordFilter, false);

function keywordFilter(node)
{
   var altStr = node.getAttribute('alt').toLowerCase();
   
   if (altStr.indexOf("flight") != -1 || altStr.indexOf("space") != -1)
      return NodeFilter.FILTER_ACCEPT;
   else
      return NodeFilter.FILTER_REJECT;                
}

For a live example, check out my demo for DOM Traversal -- I used NodeFilter extensively there. Complex filtering operations on the list of media elements were as simple as using a NodeFilter callback like the one above.

In this post, I showed that you have options in how to traverse a document. Here are suggested best practices for when you should use the various interfaces:

• If the structure of the document is important – and you’re only interested in elements – consider Element Traversal. It’s fast and won’t leave a big footprint in your code.
• If you don’t care about document structure, use NodeIterator instead of TreeWalker. That way, it’s obvious in your code that you’re only going to be using a flat list. NodeIterator also tends to be faster, which becomes important when traversing large sets of nodes.
• If the SHOW_* constants do what you need for filtering, use them. Using constants makes your code simpler, as well as having slightly better performance. However, if you need fine-grained filtering, NodeFilter callbacks become indispensable.

I’ve already found these features to be a great help in my own coding, so I’m really excited to see what you do with them. Download the latest Platform Preview, try out the APIs, and let us know what you think.

Thanks!
Jonathan Seitel
Program Manager

When we first introduced our plans for Internet Explorer Platform Previews we said that “developers and people interested in standards and web development can try out new platform functionality and provide early feedback.” We are now getting such feedback on a daily basis and are using it to improve IE9. However, sometimes the impact of the feedback extends beyond just IE9. Here is the story of how some recent feedback regarding the third IE9 Platform Preview resulted in a correction to the new ECMAScript 5^th Edition (ES5) standard for JavaScript.

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

Lost In Translation

“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

The network plays a crucial role in the overall performance of a web browser. The best way to improve network performance is to minimize the volume of network traffic by using HTTP compression and taking advantage of the browser cache.

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

A few weeks ago, we talked about the performance characteristics of our Flickr Explorer sample. We showed how hardware acceleration benefits real world scenarios such as browsing photos, and how easily web developers can build these types of applications.

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

With the recent release of the latest IE9 platform preview, we talked about how we’re rebuilding the browser to use the power of your whole PC to browse the web, and to unlock a new class of HTML5 applications. One area that developers are especially excited about is the potential of HTML5 canvas. Like all of the graphics in IE9, canvas is hardware accelerated through Windows and the GPU. In this blog post we discuss some of the details behind canvas and the kinds of things developers can build.

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

We’re focused on making Internet Explorer 9 amazingly fast, and we want to help web developers make their sites fast as well. Enabling developers to accurately measure the performance of their websites is critical to making the web faster and enabling a new class of HTML5 applications. At Velocity, we announced Internet Explorer 9 as the first browser to provide performance information to developers at runtime, which we introduced in the latest IE9 platform preview. With special thanks to Steve Souders and Zhiheng Wang from Google, the WebKit team and Mozilla.

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. 

Our commitment to  same markup includes script along with HTML, CSS, SVG, and the other markup that developers use to build the web. To make same markup real, the community needs a set of official tests to assess how interoperable and standards-compliant different browsers are with the latest version of JavaScript, “ECMAScript Fifth Edition” (fondly known as ES5).

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

Up to this point we have mostly talked about improved JavaScript performance in Internet Explorer 9 but we haven’t said much about any new or changed language features in the “Chakra” engine. Now, with the third Platform Preview, we can tell you about JavaScript feature enhancements which you can try for yourself.

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

Being all in with HTML5 means being committed to enabling developers to use the Same Markup on the Web, and that includes the same JavaScript code.

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

As developers experiment and begin the transition from writing today’s websites to building HTML5 applications, they will test the limits of browsers. For example, the huge difference between hardware accelerated HTML5 video and plain HTML5 video support in a browser was clear in the demo we showed at MIX.

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