Web 3.0, 6 Bladed Razors, 7 Minute Abs » Internet Explorer

Et tu, X-UA-Compatible?

Zach Leatherman — Mon, 07 Feb 2011 05:34:14 +0000

Or, the story of how I learned that the X-UA-Compatible header/meta tag is NOT the same as the Internet Explorer 8+ Compatibility View button.

Please note that the following information may be common knowledge, as this behavior is as described in the pre-requisite Microsoft documentation on the subject. However, I feel this behavior to be unintuitive and requiring more explicit communication.

Library developers live in a much different world from full stack developers. If you’re supplying code that will be used by others, you’re faced with a different set of priorities. As such, the library I manage provides certain user agent sniffing conveniences, namely classes to replace CSS Hacks (similar to the approach used in HTML Boilerplate to provide ie6 through ie9 classes on the tag) and JavaScript booleans (similar to jQuery.browser). Much like jQuery, these conveniences remain for backwards compatibility.

The purpose of this post is in fact not to convince you whether or not User Agent Sniffing is a good tradeoff for performance (even though, in some cases I believe it is), but instead to provide further evidence that using the User Agent alone is an unreliable method to determine the rendering engine of the web browser, and must be complemented with other approaches. If you’re going to sniff, you have to sniff harder.

X-UA-Compatible Breaks navigator.userAgent

Microsoft defines two terms to help communicate how new versions of Internet Explorer render a page: Browser Mode and Document Mode. Browser Modes are determined prior to any request made to the server (and cannot be changed by web developers). If the user triggers an IE7 Browser Mode using the Compatibility View Button, a new request is made to the server. Document Modes are determined in the page response.

Compatibility View Button Flow

User presses the Compatibility View button. This changes the Browser Mode.
Request sent (since the Browser Mode has changed, the User-Agent is also changed to MSIE 7.0)
Response from Server
Document Mode determined

X-UA-Compatible Flow

Internet Explorer uses the default Browser Mode (newest available in the browser)
Request sent (Browser Mode determines User-Agent to send, probably MSIE 8.0 or MSIE 9.0)
Response from Server. Content may include X-UA-Compatible tag and/or Response HTTP headers such as X-UA-Compatible).
Document Mode determined, using X-UA-Compatible and the DocType

If a X-UA-Compatible header is sent back in the Compatibility View flow, it will take precedence but obviously will not change the request User-Agent HTTP header.

It’s important to note that since the request has already gone before the Document Mode is determined, the Document Mode has no bearing on the request User-Agent HTTP header. ~~While Microsoft probably could have changed navigator.userAgent to be different than the request User-Agent HTTP header, I feel they made the correct decision is keeping the same value.~~ navigator.userAgent remains the same value as the request User-Agent HTTP header in IE8, but Microsoft changed this behavior in IE9. In IE9, navigator.userAgent represents the document mode, not the request User-Agent header.

The User Agent isn’t the only thing being determined. The prerequisite Microsoft documentation states that the Browser Mode determines the User Agent, Default Document Mode, and Conditional Comments. This is not accurate. The Document Mode determines which Conditional Comments execute, not the Browser Mode.

Also note that using IE’s Conditional Compilation feature to return the version of JScript will be the same, independent of Document Mode.

var ie = /*@cc_on @_jscript_version+@*/0;
// Always returns 5.8 in IE8, independent of Document Mode.

Example Code from Scott Jehl’s respond.js

Test Pages

Try the following tests in Internet Explorer 8+ to test for yourself.

What Does This Mean?

If you use X-UA-Compatible to change the Document Mode/IE Trident rendering engine, any client side code relying on navigator.userAgent (such as jQuery.browser) or server side code relying on the User-Agent HTTP Header will be incorrect. Since we can’t rely on the User Agent, what can we use? Microsoft does provide a document.documentMode integer we could use, pretty easily. But, I think there is a better approach.

Consider a great piece of JavaScript written by James Padosley to find Internet Explorer version numbers using Conditional Comments. His code seemed to meld perfectly with the above realization that the Document Mode determines Conditional Comment execution. We can use this to fix jQuery.browser.

// Place this script after jQuery, but before any code that uses jQuery.browser
// Modified to only test for IE 6+, since jQuery only supports 6+
(function($)
{
    if(!$.browser.msie) {
        return;
    }
 
    var v = 5,
        div = document.createElement('div'),
        all = div.getElementsByTagName('i');
 
    while (
        div.innerHTML = '',
        all[0]
    );
 
    $.browser.version = v;
})(jQuery);

Now, of course, since we’re creating nodes there is a small performance penalty in using the above script over Regular Expressions and document.documentMode. I feel this to be worthwhile, given that I’ve been burned by Internet Explorer’s version number before. But next time, I reserve the right to choose performance over simplicity.

Internet Explorer Array.sort Unreliable

Zach Leatherman — Thu, 25 Feb 2010 02:09:52 +0000

What would you expect to be the result of executing the following code?

// Create a medium size array, at least 100 items
var obj = [];
for(var j=0, k=150; j<k; j++) {
    // the value here doesn't matter.
    obj.push('ABCD'+j);
}
 
// Sort the array alphabetically.
obj.sort(function(m,p){
    m=(''+m).toLowerCase();
    p=(''+p).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

The obj Array should now be sorted, in alphabetical order based on value. BUT, in our best friend Internet Explorer, a Number Expected error may be the result. Don’t be fooled if your test array behaves correctly, it only happens intermittently for arrays of varying size!

So, I whipped up a quick test to check the damage. Iterating over array sizes from 1 to 150, running the Array sort algorithm. The following failures resulted:

Browser	Failures *
Internet Explorer 6	4 sizes out of 150
Internet Explorer 7	18 sizes out of 150
Internet Explorer 8 (and Compatibility Mode)	2 sizes out of 150
Internet Explorer 9 (and Compatibility Mode)	0 sizes out of 150 (Fixed!)

* Failures may vary to the specifications of the test machine.

Of course, the Number Expected error is going to result whenever your code doesn’t return a number inside of the function callback. But the problem here is something deeper than simple application code failure. The problem is in JScript itself. Any modification to the sort arguments may result in the Number Expected error.

    m=(''+m).toLowerCase(); // modifies the argument m and is unreliable.

This problem will manifest itself more frequently if you use the Google Closure Compiler, which restructures JavaScript to reuse argument variables if possible, probably to save the 4 character penalty of a “var ” declaration.

Normally, reusing argument variables is a safe practice for primitives, since they are passed by value and not by reference, as is the case in this Array sort example ¹. So, what exactly is going on here? One commenter at the Google Closure Compiler bug seems to think that the actual array values are being passed by reference instead of by value. I’m not completely convinced that’s the case.

The Fix

Don’t reuse the argument variables inside of an Array sort function.

// Changing the above example
obj.sort(function(m1,p1){
    var m=(''+m1).toLowerCase(),
        p=(''+p1).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

Check the source code of the demo file to see the different methods of modifying the arguments that I attempted.

If you want to learn more about passing by value or reference, Jonathan Snook has a nice explanation.

Internet Explorer can’t make you do anything, it can only make you wish you hadn’t.

Updated: Added note about Internet Explorer 9 and its Compatibility View. Looks like it’s fixed!

Don’t Give Up on Internet Explorer Yet

Zach Leatherman — Thu, 10 Dec 2009 03:24:46 +0000

These days, the browser landscape is more fragmented than ever. Were times easier back when IE6 and Firefox ruled the internet? Easier perhaps in terms of the number of browsers you had to launch for testing, but not better for any user’s experience. We are in a new world, where more web browsers are causing developers to become increasingly pragmatic with their designs and code. Sure, standards have created a safe haven under the newest versions of the Big 3 (Firefox, IE, Safari), but the lay majority are still using whatever default has been installed onto their computer, and they probably can’t tell you the difference between their web browser and a search engine.

We must be resilient to resist the transformation from development pragmatism to user abandonment, especially considering a developer’s trend of being insulated with the latest equipment. We use the newest hardware and download the most sophisticated browser software because we want the best experiences. We stack the cards in our favor. The difficulty lies with the populace that want a good experience (they can tell a fast site from a slow site), but they don’t want to buy new equipment or install a better browser. So the question has become: Where do you place your chips on the spectrum balancing modern hardware/software and the user experience?

As web developers, it has become increasingly easy to become disenfranchised with the lay majority’s computing environment. I’ve witnessed this personally after purchasing my first Apple computer, a device curiously immune to the plague of IE 6/7 (8 as well, but I would hesitate to label it as a plague, more like a normal run of the mill flesh eating virus). It’s an interesting phenomenon, being cutoff from the Windows environment (save virtualization) during development. It’s delightfully tempting to declare damnation upon the plague ridden Internet Explorer Zombies, and develop your web presence to standards alone, allowing less focus on the harshest development environment imaginable and more on actual problem solving.

When developers engage in quasi-web development, perhaps in the form of an iPhone specific web application or an Adobe AIR desktop application, it fosters similar feelings. The work shares many languages and technologies with real (wide-open) web development, but is targeted towards a single web browser. This benefits of this sort of tunnel vision device targeting must be carefully weighed against the penalties you’re paying in narrowed default-install client compatibility. At that point, it’s just friends with benefits.

Google Wave, in fact, requires the use of Safari, Firefox, Chrome, or the Google Chrome Frame plugin (which doesn’t count as actual browser support). As of the time this article was written, as many as 64% of all users (source) are met with the above screen when trying to access Google Wave. Let’s be clear: Ease of development is not an excuse to abandon users. Whatever happened to Device Independence?

Not surprisingly, Google Wave’s stand against Internet Explorer has not started a trend. Instead of all out war, the community at large has decided that subtlety is what’s needed to win this fight. Let’s hold back the sexual healing of rounded corners, even though perhaps users will call our design harsh or cold. Let’s give them plain buttons instead of nice three dimensional buttons with text and box shadows, even though they may be less actionable.

Let’s make it easier on ourselves at the expense of the user experience of The Zombie Majority. We make this sacrifice because we assume that Zombies won’t be able to tell the difference between eating a big juicy Einstein brain and a smaller but nonetheless still tasty brush clearing George W. And you know what, I think we’re right.

Updated to include a few more thoughts on Adobe AIR and the iPhone.

Forward Compatibility and JavaScript

Zach Leatherman — Fri, 02 Nov 2007 01:53:20 +0000

Many developers (myself included) complain endlessly about the problematic ECMAScript implementation that Internet Explorer uses called JScript. And after reading one such very detailed complaint in the comments on Dave Massy’s website at MSDN, and reading Chris Wilson’s post about ECMAScript 3, it has become increasingly obvious of Microsoft’s opinion on the subject of Forward Compatibility with JavaScript. It’s something they keep pounding their fists on the ground about, how they are adamant that new versions of their browser not “Break the Web.”

Of course, “Breaking the Web” refers to the amount of code on the internet today that is an equal and opposite reaction to the broken bug-ridden JavaScript implementation of their browser. It describes the unimaginable future in which Internet Explorer fixed the many well documented intricacies of JScript and thereby ruins the code that was originally written to support the problem. What a conundrum.

But haven’t we already been through this problem? Isn’t this the same exact thing we saw in the early days of CSS? And how did the major browser players react? By implementing both a Quirks and Standards mode for CSS through DocType switching. Now my question is:

Why haven’t we seen a Quirks and Standards Compatibility Mode for JavaScript?

I’m not necessarily encouraging the Quirks and Standards modes to be toggled with the DocType (as with CSS), but why not have these two modes? To enable your site to use the Standards mode of JavaScript, the browser might require a certain DocType to be declared, or it might require a different script type in the browser:

I-Frame Shims or How I Learned to Stop Worrying and Love the Bomb

Zach Leatherman — Tue, 24 Apr 2007 21:51:55 +0000

So again, I show up late to the party. IE7 is already out, but my target customers are still using IE6. So today, boys and girls, we’re going to discover the magical world of using I-Frame shims to hide those bleeding heart select boxes from showing through our layered elements.

Typically, when creating an I-Frame shim, you’re going to create the i-frame dynamically using document.createElement. Let’s start out with some successful code.

var iframeShim = document.createElement( 'iframe' );
iframeShim.setAttribute( 'src', 'javascript:"";' );
iframeShim.setAttribute( 'frameBorder', '0' );

Now for some caveats you might have encountered with code not matching the above:

I-Frame frameBorder attribute
Are you trying to get rid of that nasty i-frame border in Internet Explorer 6 (IE6)? Tried CSS properties? Tried setting the frameBorder attribute? It turns out that when setting the frameBorder attribute, the name of the attribute is case sensitive. Using frameborder will not work correctly, but using frameBorder (with a capital B) will give the desired result. [Source: FlashApe]

HTTPS and I-Frame src attribute
Is your page hosted on a secure domain (https instead of just http)? Is the dynamically created iframe causing the following error message in Internet Explorer?

This page contains both secure and nonsecure items. Do you want to display the nonsecure items?

Some have suggested that changing the src attribute to point to a blank html page with no content is the solution, but that’s an extra http request on your page that is unnecessary. Others have suggested that that changing the src attribute to javascript:false works. It does, in fact, but writes the text ‘false’ to your iframe content. Others have suggested javascript:void(0) as your src attribute value [Source: ewbi.develops], but some Internet Explorer clients still have secure and nonsecure items alert popup. I have not figured out the factors that separate these Internet Explorer clients.

Update: The correct solution is in face setting “javascript:false;document.write(“”);” as your src value, as I found in the jQuery BlockUI plugin. This is a silver bullet fix that will avoid all the problems I have encountered.

Update Again: I have revisited this problem and it looks like (as mentioned in the comments) there is a problem with the solution presented in the first update (infinite load). After researching some DOMContentLoaded solutions, I thought to try the “//:” source they were attempting for their deferred script source. Alas, it didn’t work. However, javascript:""; does work, so the above solution has been modified. Keep in mind, the whole point of this solution is to avoid an additional unnecessary HTTP request.