Meta Madness

Wanna know how I can tell that no other browser vendor participated in the creation of the new meta X-UA-Compatible tag? Because it’s completely worthless – and in fact harmful – for any browser to implement!

I love this example from the overview article, including Firefox 3 as an example:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

What seems to have slipped past the Microsoft Task Force of WaSP (or maybe it didn’t and they’re just playing coy) is that by implementing this specific feature in any other browser immediately either: A) Reduces its market size of viable web pages that will upgrade to new versions of the browser or B) Forces new versions of the browser to bloat, including backwards support for old-style rendering.

The fundamental issue is that Safari, Firefox, and Opera will all be harmed by attempting to implement this. Anne, from Opera, completely agrees. So, with that in mind, why even the attempt at making this sound like a “generally beneficial standardization issue”? Why go through the song-and-dance? Because if it was called:

<meta http-equiv="X-IE-VERSION-FREEZE" content="IE=8" />

then developers would surely, excuse me, shit the bed in frustration over being forced to add markup just to make their web applications render in a standards compliant manner. The comments on the article definitely indicate some level of this occurring already. However, the pretense of cooperation and generally applicability needs to be dropped. It doesn’t exist, it’s a complete lie, and any indication of general use is a sham. Call it for what it is: A shiv for jamming standards support into future versions of Internet Explorer.

JavaScript and X-UA-Compatible

With that rant out of the way, how will this new meta tag addition effect JavaScript and DOM support in future versions of Internet Explorer? That’s the weird part – no one completely knows. Let’s look at some randomly-picked issues that are sure to cause a world of fun in the future.

Cross-document issues

Let’s say you have a page that’s in IE7 mode and an iframe pointing to a page that’s in IE8 mode (or vice versa) – and now you communicate across the frames. Now let’s assume, for fun, that IE8 also support JavaScript getters and setters.

var iframe = document.getElementsByTagName("iframe")[0];
iframe.contentWindow.someObj = { get value(){ return true; } };
iframe.contentWindow.someObj.value // ??

What happens when you bleed functionality across frames? Or even if you were to try and access functionality that doesn’t exist in your engine from another? Who knows! This is positively frightening both from an implementation and user perspective.

Another random item: What happens when you use importNode across iframes that have different DOM versions?

Robert O’Callahan, Mozilla developer, has two blog posts on the subject that are both quite good.

Script Versioning

Up until this point, if we wanted to pick a different version of JavaScript to use we would do something like the following:

<script type="application/javascript;version=1.8">...</script>

This works well in browsers that support it. However, with this new meta tag addition, Internet Explorer is pegging JavaScript versions to versions of their rendering engine. This means that (theoretically) if you wanted JavaScript 1.5 support you’d have to, also, be content with bad CSS support. If you wanted to upgrade to a new version of the scripting engine you’d also have to upgrade your CSS and markup as well. This is completely throwing out any sort of versioning system that already exists for JavaScript and forces users to use this new, inferior, system instead. How completely frustrating.

What I also find interesting is that, previously, Chris Wilson was concerned about implementing multiple versions of a JavaScript engine in order to maintain backwards compatibility. What they’re doing now is, effectively, forcing themselves to have multiple JavaScript engines. So either they’re gearing up to support JavaScript 2 or they’ve just lost one of their major qualms with the upcoming specification.

Minor Versions and Security Fixes

A final point that doesn’t seem to be accounted for, at all, is the inclusion (or exclusion) of minor browser versions (including things like security patches). Internet Explorer hot patches have been known to cause problems in the past with web page functionality and rendering. However, since there’s no way to specify which patches you “like” in this new meta tag scheme you’re forced to consume them all.

The end result will be one in which: A) You’re either constantly dodging mistaken bullets from the Internet Explorer team as the push out new releases or B) They’re not going to do as many, if any at all, updates to the browser out of fear of breaking backwards compatibility. Honestly, I assume that B is far more likely, therefore you can be excited about looking forward to future, static, bug-laden releases of IE in the years to come!

On a whole, I really wish that this process had been done more in the open than it was. I doubt that as many issues, that we’re seeing now, would’ve arrived. I absolutely don’t envy Internet Explorer’s situation in the matter so, for the sake of the web, let’s hope they come up with an acceptable solution.

Posted: January 22nd, 2008

Subscribe for email updates

40 Comments (Show Comments)

Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.

Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.