Monthly Archives: November 2013

Emulation Accuracy in Internet Explorer

Early preview versions of Internet Explorer 11 lacked Emulation features that we saw in Internet Explorer 9 and 10. When Windows 8.1 shipped, Internet Explorer 11 was found to have the Emulation features shipped with it. These tools are helpful, though they can be misleading at times.

My general workflow in the past when using these tools goes like this: A user reports an issue in Internet Explorer x. I instruct the latest version of Internet Explorer to emulate the reported version. If I encounter the same issue, I can debug using the modern version of Internet Explorer. If emulation does not reveal the same issue, I need to load up a virtual machine, or use a service like BrowserStack.

The problem with these tools is that it’s not entirely clear where the line of reliability resides. To what degree this emulation replicates the native experience is unknown (to me, at least). Due to this, I’ve decided to do a deep dive into Emulation and see just how reliable it is, and in which areas.

Computed Styles

The first dive wasinto Computed Styles. Does Internet Explorer generate the same computed styles as IE10 and IE9 when it is emulating those versions? Surprisingly, yes. Granted, I’m running instances of IE10 and IE9 in a Virtual Machine (compliments of modern.ie), so that should be considered. Also other important thing to note is that this pass-through assumes Standards Mode.

The comparison tables are being maintained in a Google Docs spreadsheet. Click the preview below for the full view.

comparison.table

Window Object

My next focus was on cycling over enumerable properties on the window object and laying those out for comparison. A cursory glance of this next table will reveal that Internet Explorer 11 emulates the window object from IE9 and IE10 very well. Granted, there are some very clear examples of where it brought along a couple extra methods and properties.

comparison.table.window

It’s worth noting that this particular table had to be done a couple of times. Some of these members don’t attach themselves to the window object until certain actions are performed. For instance, this table is front-loaded with a bunch of BROWSERTOOLS members that are pushed onto the window object when various portions of the developer tools are opened. Other members, such as $0, don’t exist until you perform an action like selecting an element in the DOM Explorer.

More on GIFs and Painting in Internet Explorer

About a week ago I wrote a post demonstrating the use of UI Responsiveness functionality in Internet Explorer 11 to determine how the browser handles animated GIFs in various states. This post was a fairly well-received so I wanted to expand a bit more upon it and cover a few more scenarios.

For the most recent round of testing, I setup a simple interval to change the className of the body element every few seconds. This, in turn, affects the placement and layout of a single image element within the document.

(function () {

  "use strict";

  var states = ["", "opacity", "visibility", "offscreen", "perpendicular"],
      container  = document.body,
      cycles = 0,
      nextState;

  function advanceState () {
    // Advance to next array index, or return to start
    nextState = states[++cycles % states.length];
    // Indicate a new performance mark in our developer tools
    performance.mark(nextState ? "Starting " + nextState : "Restarting");
    // Update the body class to affect rendering of image
    container.className = nextState;
  }

  setInterval(advanceState, 3000);

}());

I used the performance.mark method to add my own indicators in the performance graphs to help me identify when the demo was transitioning into a new state. These performance marks are represented in Internet Explorer by small upside-down orange triangles.

performance.ticks

Let’s walk through each of these triangles left to right, discussing the state they represent.

GIF Untouched

This state is represented by all activity to the left of the first performance mark. Not much needs to be said – Internet Explorer continued to paint the GIF as it sat animated on the screen.

performance.ticks.0

Setting GIF Opacity

This step is represented by all activity between the first and second performance marks. In this step, the image element has its opacity property set to 0. Even though the image is no longer visible, the browser continued repainting the region occupied by the image element.

performance.ticks.1

Setting GIF Visibility

This step is represented by all activity between the second and third performance marks. In this step, the image element has its visibility property set to hidden. Once the visibility property was set to hidden, the browser made one final repaint (presumably to hide the element) and no further paint events took place during the duration of this state.

Of relevance here is that the hidden attribute on the image itself has the same effect. When this attribute is present on the element, Internet Explorer will cease to repaint that elements occupied region.

performance.ticks.2

Setting GIF Outside of View

This step is represented by all activity between the third and fourth performance marks. In this step, the image element is positioned absolutely at top -100% left -100%. In spite of the fact the element is positioned outside of the viewport itself, the browser continued to run paint cycles.

performance.ticks.3

Setting GIF Orientation Perpendicular to Viewport

This step is represented by all activity between the fourth and fifth performance marks (the fifth mark is the ‘Restarting’ mark). In this step, the image is rotated using the transform property so as to set it at a right angle to the viewport, effectively hiding its content from the viewer. This orientation did not affect the browser paint cycle, and Internet Explorer continued repainting the region occupied by the image element.

performance.ticks.4

Conclusion

As a general rule, it appears Internet Explorer will run paint cycles for every animated GIF in the document, unless that element has its visibility property set to hidden. This is fairly reasonable, since setting visibility to hidden is the only explicit way to tell the browser not to render the element. Keep this in mind when performance is of key importance.

After running through and investigating this further I was curious what the same test would reveal in Chrome. I was pleased to see that Chrome would cease to paint for the opacity, visibility, and offscreen configurations. No performance marks are revealed in Chrome’s developer tools, but you can identify the timer functions by the presence of a small orange mark.

performance.ticks.chrome