Tag Archives: Internet Explorer

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.


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.


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.

Tracking GIF Repaints with UI Responsiveness

I recently came across Paul Lewis’ article Avoiding Unnecessary Paints: Animated GIF Edition on HTML5 Rocks and wanted to contribute a bit to the message. If you aren’t a regular reader or HTML5 Rocks I would definitely encourage you to visit often.

The summary of Lewis’ post is that animated GIFs can cause repaints even when obscured by other elements. So even though you may not see the GIF, the browser may continue to repaint every frame of it.

As far as browsers go, Lewis shared with us the “Show paint rectangles” feature in Chrome. When enabled, this feature will visually outline regions that are being repainted. This obviously makes it very easy to determine whether paints are happening on obscured elements. Chrome, Safari, and Opera all repaint. Firefox does not.

In his discussion of various browsers, Lewis calls Internet Explorer 11 a “black box,” suggesting it gives “no indication whether repaints are happening or not.” As a result, no statement was made speculating whether Internet Explorer was in the camp of Chrome, Safari, and Opera, or Firefox.

I quickly did a scan of the comments to see if anybody addressed these words regarding Internet Explorer, but at the time nobody had. I saw this as a great opportunity to introduce my friends to the new UI Responsiveness tool in Internet Explorer 11.

The UI Responsiveness tool in Internet Explorer’s Developer Tools will actually give us pretty granular information about frame-rates, script timing, styling changes, rendering, and even repaints. Given the novelty of this feature in Internet Explorer, I felt it would be good to provide a quick example of how Internet Explorer 11 can indeed tell you whether obscured GIFs cause repaints or not.

A Single Visible GIF

My first experiment consisted of nothing more than a single GIF in the body of my document. By profiling the page for a few seconds I could see that there was constant repainting. This was expected of course, after all there’s a GIF on my screen spinning.

Below is one second of activity. As you can see, constant repainting.


Toggling Visibility of a Single GIF

Next up, toggle the visibility of the GIF by way of its display property. I setup a interval to flip the visibility every second. The results were also as expected. For roughly one second, we had constant repainting. Following this we saw a set style event, followed by a single repaint (to hide the element). At this point, it was silence for a second before the element became visible again, and thus began causing additional repaints.


Routinely Obscuring a Single GIF

The last experiment was to add another element, a div with a solid background-color in this case, and obscure the animated GIF on an interval. This was done by positioning both the div and the image absolutely within the body, and giving the div a higher z-index.

As can be seen in the image below, repainting did not cease even when the layout was adjusted every second. This demonstrates that when obscured, animated GIFs will continue to cause repaints in Internet Explorer 11. Whether this will be the case for future versions of Internet Explorer remains to be seen.



So as we can see in these examples above, Internet Explorer 11 is capable of sharing vital information about costly repaints. Additionally, IE falls into the Chrome, Safari, and Opera camp. It sure would be nice if all browsers followed Firefox’s lead here and stopped repaints on obscured GIFs, but perhaps there is a good reason they haven’t, who knows.

I hope you can see the enormous value the UI Responsiveness panel in Internet Explorer 11′s Developer Tools brings to the debugging experience and use it to make your projects more responsive and performant in the future. The team behind Internet Explorer really have been doing amazing work lately, and the UI Responsiveness functionality is but one example of this.

UPDATE: More on GIFs and Painting in Internet Explorer

Hacking Windows 8 Snapped Mode

I recently updated four machines of mine to Windows 8.1. Love it, not a thing I would change (talking high-level here). But one of my favorite features continues to give me a slight headache.

In Windows 8 you have the ability to “snap” a web-browser to either side of your screen. This is great if you’re trying to keep documentation up, an in-browser chat visible, or even some productivity tools that are browser-based.

Sadly, many of the sites I snap wind up getting reduced so badly that I can no longer make out what is on them – kinda like how browsing the web is when you’re on a small mobile device, and the site you’re viewing isn’t “responsive” in a cross-browser compat way.

As an example, here I am trying to use wunderlist (awesome service) on my Acer Aspire R7.

Wunderlist in Snapped Mode.

Wunderlist in Snapped Mode.

Ideally I would just contact Wunderlist and have them fix their site for IE in Snapped Mode, but that isn’t always easy. Fortunately, there happens to exist a feature in IE that we can leverage – custom accessibility stylesheets.

In order to find this setting, click the Gear icon (or press alt to reveal your toolbar, and then click “Tools”) > Internet Options > General [tab] > Accessibility [button]. Alternatively, you can press the Gear icon

Internet Explorer on Windows 8 uses the same settings whether you’re in the Desktop mode or the Immersive (“Metro”) mode. As such, all we need to do is create our own custom stylesheet that will be applied to every website we visit. With this, we can set the new viewport size on our own.

Setting custom stylesheet in Internet Explorer.

Setting custom stylesheet in Internet Explorer.

I should note here that after setting (or updating) your stylesheet, you will need to close and re-open Internet Explorer (That’s a feature I’d like to see changed). This was really bugging me since I would make changes, and refresh, only to see no changes at all.

In the screenshot above you can see that I tossed in a basic media query to set the viewport to 320px wide anytime the browser itself was 400px or less in size. The result is immediately seen when you re-open Internet Explorer and pull up Wunderlist.

Wunderlist, with our custom stylesheet in place.

Wunderlist, with our custom stylesheet in place.

The end result is a far better user experience, and something I can now use in parallel to my daily work. I hope this works for you, and you find the Snapped Mode as enjoyable as I do.

You may have to add a bit more to your stylesheet to target certain websites, etc. This basic example was meant to address one site only. A real-world application would be ever-changing to accommodate sites and services you come across in your daily routine.

Hack on, hackers.

Taking the Internet Explorer Challenge

I’m going to use Internet Explorer 10 as my primary browser for one week. That’s one week without browsing, tweeting, or listening to turntable in Chrome (current “Browser of Choice”). That’s one week deep inside the bowels of the browser that burned me, and so many of my peers, so badly over the last decade. One week in the heart of the beast.

Why? Isn’t Internet Explorer supposed to be a thing of the past? A bad phase in the history of the web that we’re slowly recovering from? The faint image of the broken internet from yesterday, replaced by far more standards-compliant browsers like Firefox and Chrome? Well, yes, and no.

If I’m honest with myself, and everybody else, it’s not the browser that burned me. Internet Explorer dominated the market back in the day when I got excited to see 3kb/sec downloads. It was installed along side Netscape Navigator, but won me over pretty quickly.

The browser won a lot of people over, including corporations who went on to develop internal applications that depended on its implementation of HTML, CSS, and J(ava)Script. And then the world changed around them; around all of us.

Dial-up was becoming a thing of the past, and new browsers were creeping into the scene. Firefox rose like a phoenix from the ashes of Netscape, and then Google got into the game with Chrome. These later browsers took advantage of faster and more consistent connections and offered streamlined updates that happened silently in the background.

Internet Explorer was still dominating in the global market, but these antiquated versions from yesteryear were still in circulation, and still being actively used. While they were once the apple of our eye, we quickly jumped from them to the new breed of browsers. It wasn’t that Internet Explorer 3-8 were bad – they weren’t. It was the fact that the world around them changed, and changed quickly.

Fast forward to Internet Explorer 10; it is new, and has great support for standards. Most importantly though, it hints at having the capacity to auto-upgrade like its competition. So I was curious, do I have any reason to dislike Internet Explorer any longer? Is it just as good as Google Chrome, Mozilla Firefox, or Opera? What better way to find out than to use it as my primary Browser of Choice for one week.

Sunday, Bloody Sunday

It’s really tough retraining my mind to click my Internet Explorer icon instead of my Chrome icon. The icon that was once relegated to testing and debugging my code in yesterday’s browser is now my go-to destination for all casual browsing, tweeting, and more.

So far I’ve been using Internet Explorer for Bootstrap work, blogging from WordPress, Tweeting with TweetDeck, Facebook, and casual browsing online. While I didn’t spend much time in the browser today, I did do some tweeting from @tweetdeck’s web-application, and noticed that the scrollbars are pretty horrible looking – so I fixed them. Left and right for before and after.


Unfortunately it appears Twitter has neglected Internet Explorer when they developed their dark-theme. While they fixed up the styles for the scrollbar in WebKit, they failed to do anything remotely similar in Internet Explorer. I’ve notified them (and might have gotten their attention), so let’s hope they get word and make these changes. You can make similar changes in your applications using scrollbar-face-color and related properties (See the “see also” section on the previous link).

I must admit, it would be awesome if we could control the properties of the scrollbar by setting properties on a pseudo-element instead of on any element that scrolls. It’s worth noting that in this territory, there currently is no w3c-accepted standard.

IE uses a proprietary extension in the form of prefixed-properties, and WebKit uses a proprietary extension in the form of prefixed-pseudo-elements. One can only hope there will be a consensus and convergence in implementation.

No Case of the Mundays

Today was my first actual day of work in Internet Explorer. I mean, I’ve opened it up here and there during work in the past, but today I spent all of my time in Internet Explorer – and it went well. Nothing broke (that I noticed), nothing was complicated, all was well.

I did work on a CSS example for somebody today only to have them say “the antialiasing sucks,” but as it turned out they were viewing in Chrome, and I was viewing in Internet Explorer. Sure enough, if you create a hard-edge on an angled CSS gradient, it looks better in Internet Explorer than it does in Chrome. Here’s a quick comparison between Chrome 25 and Internet Explorer 10.


This particular gradient is 25deg – oddly enough, Chrome draws a beautifully-smooth line when the gradient is changed to 45deg rather than 25deg. Don’t ask me why – I haven’t the slightest clue.

OMG, Tuesday!

Wow, so today was a big day. When I started this blog post I was a little bummed that the only people able to take the IE Challenge would be those who have purchased Windows 8, or a machine that came loaded with Windows 8. This morning at 6am PST, the IEBlog announced Internet Explorer 10 for Windows 7!

On to my day though – today was spent largely in Google Docs. I noticed there were some small layout differences between Chrome and IE. For instance, the number of characters you can fit on one line before a wrap occurs differs in Chrome than it does in IE. This was particularly bothersome since one of my templates features right-aligned text left-padded with enough spaces to complete a full line of characters. All of these characters are then set with a dark background color.

I wound up taking an alternative route, replacing this approach with a single-cell single-row table, and setting the background color of the cell instead of the background color of the text. This was far better and gave far more consistent results between IE and Chrome. No clue who is to blame, or what was the means by which both browsers diverged from one another, but Chrome appeared to hold itself together better overall when it came to Google Docs.

Wednesday, Thursday, and Friday

So at this point it’s just difficult to find things to blog about. I instinctively click on the Internet Explorer 10 and go straight to my browsing. I don’t experience any issues with my favorite sites. I tweet using TweetDeck, check in with Mom on facebook, drop images into imgur, broadcast using Google Hangouts, manage a channel on YouTube, help out where possible on StackOverflow, and blog about all of it here in WordPress – no issues. Everything just works.

I don’t mean to give the impression that there isn’t any work to be done – there is, a lot. Sadly, while the Internet Explorer developers have been doing an amazing job with their product, we (the community) need to step up our game as well. We’ve got to start writing better code, and paying attention to language specifications and APIs, as well as the ways in which they’re implemented in various browsers.

I came across another “my site doesn’t work in IE” thread today. The website popped up in Quirks mode. Changing it to Standards didn’t magically fix it (as it does from time to time). Instead, pushing it to Standards mode resulted in an even more damaged experience.

The problem here was written all over the Source: apathy, carelessness, and so much more. We aren’t teaching passion for our craft today as well as we should. We teach people how to hammer out some markup, and then encourage them to feed off of the visual presentation, rather than the compliance to the specification (too). New developers code, and refresh, code, and refresh. Rarely, if ever, making a trip to w3.org.

In early 2012 I came across a rather iconic website that was rendering well in Chrome and Firefox, but the side-bar navigation (made up of lists within lists) was severely broken in Internet Explorer 9. The problem wound up being an unclosed list item; I modified the response in Fiddler, issued a new request in IE9, and the page magically worked. This designer tested their markup in a browser that deviated from what the code explicitly requested (nasty nesting), and instead did what it thought the designer intended. While this resulted in the proper formatting, it breaks the web.

This was something I grew to appreciate in Internet Explorer 9 – it was brutally honest. You got what you asked for (generally speaking), and when your document was looking ugly, it was because your code was telling it to. Other browsers would implement a dose of speculation into its rendering process, which adds far too much variability to the web.

Not Perfect, But Better

A week of using Internet Explorer as your primary browser convinces me of at least two things: 1) Microsoft has come a long way with their product, and it deserves a second look. And 2) There’s still work to be done. While surfing the web on Internet Explorer 10 doesn’t feel like sucking on broken glass, it still leaves some areas for improvement.

I try to be a little less critical about massive software, given the enormous complexity to create, develop, and maintain it, but there are areas where Internet Explorer 10 can be improved. I come across these items from time to time, and try to create simplified reproducible examples when possible to share with others (and with whomever I have access to within Microsoft). One such issue is the :hover bug related to table-rows. You can see this online at http://jsfiddle.net/jonathansampson/FCzyf/show/ (Tested in Internet Explorer 10 on Windows 8 only).

Even with its flaws, Internet Explorer is still leading the way in other areas. It’s currently one of the only browsers to support pseudo-element animation, the Pointer model (though you can get ‘Pointium‘), and some CSS level 4 text properties.

My biggest concern lately is not with the browser itself, Microsoft has convinced me that their product is reliable. What concerns me lately is with the release cycles. Can they keep this new browser breathing, or are they going to continue resuscitating it on a bi-annual cycle? If so, we’ll quickly find the web moving out ahead of it again, and history will repeat itself. I find a glimmer of hope in the newest “About Internet Explorer” dialog.

Install New Versions Automatically

In my sincere opinion, Internet Explorer (in just a few years) went from being the bane of my existence (#somuchdrama), to being a bright luminary, back competing in the pack of modern browsers. Will it stay among the pack? Time will tell. Until then, welcome back Internet Explorer.

Download Internet Explorer 10, give it a week, and post your results below.

Internet Explorer 10 on Windows 7

Over on the IEBlog Microsoft just announced the official release of Internet Explorer 10 for all Windows 7 users. This is tremendous news considering the great deal of support for web-standards that Internet Explorer 10 has over Internet Explorer 9. Apparently there a number of serious performance enhancements done as well.

All Windows 7 users (well, assuming they have a legit copy of Windows 7 I presume) can download the latest browser from Microsoft today, and begin to participate in the more modern web. Anybody running the Release Preview of IE10 on Windows 7 will be auto-updated today, and in weeks to come we will see instances of IE9 auto-update to IE10.

This is a good day for the web!

Flexible Browsers

I overheard a comment a few days ago that a friend made regarding the default layout of Internet Explorer; namely its placing of the address bar inline with tabs. This results in reduced space for tabs, thus reduced title lengths, thus reduced efficiency managing multiple tasks in parallel.

Chrome, on the other hand, places the tabs above the address bar, giving the impression the address bar is part of the tab currently-opened tab. Firefox, and Opera both also place the tabs above the address bar. Every browser appears to write in stone their tab-placement – though Internet Explorer appears to show the most flexibility.

Upon exploring Internet Explorer following my friends comments, I soon found that I could resize the address bar, re-arrange the stop/refresh buttons, drop tabs down onto their own line (or leave them inline), reduce certain toolbars down into command buttons to minimize space-used. Needless to say, I was pretty impressed with just how much flexibility I found in Internet Explorer.

Here are a few arrangements I went through:

Exploring Varation in Internet Explorer's Layout

Exploring various customizations of the address bar, tabs, and more in Internet Explorer.

As previously mentioned, the above shows the resizing of the address bar, shifting of the stop/refresh buttons from the right over to the left (easier to avoid accidentally clicking the Compatibility View button), dropping tabs onto their own line (you can leave them inline, if that floats your boat), collapsing toolbars like the LastPass one into the command region, and making it inline with the favorites.

Of the four browsers I checked, Chrome appears to be the most rigid. As for customization, you can change the theme, but this is really not much more than swapping out a background image on browser itself. You can’t change the address bar width (well, you can resize the add-on bar, which results in a longer/shorter address bar), the placement of the tabs, the locality of the buttons or anything. You can, however, toggle the “Home” button on and off.


Both Firefox and Opera have really impressive options for customizing your toolbars, but that might be a degree of control that few people enjoy. I personally explored it, but didn’t find it too appealing. Also in Firefox you can disable tabs until you explicitly request to open a link in a second tab. This too reduces used-space around the “chrome” of the browser.

Opera sports an even more advanced set of options for Tab Bar Placement. While tabs at are traditionally at the top of the content (following their real-world exemplar of manila folders), you can place them on any side of the viewport in Opera. The changes of the layout are pretty drastic, so I apologize for the disorienting effect of the following gif:

Tab Bar Placement in Opera.

Tab Bar Placement in Opera.

My take-away is that Chrome is nice on the eyes, but far too rigid with the layout options. Opera and Firefox go to the other extreme, and drop enough tools in your lap that you’d need an engineer’s manual to truly understand the power you’ve been given. Internet Explorer hits closest to the sweet spot in my sincere opinion. While I wish Internet Explorer had a few features we’ve come to love in its competition, I am happy with the degree (and limits) of flexibility Microsoft has chosen to provide.