Hall of Bright Carvings

I didn’t really want to get caught up in the technical stuff about it, but I thought it was a good idea if I did my best to wrap my head around what is a really, really, really confusing issue.

Come with me, kids. We’re going on a trip.

If you open the developer toolbar in IE8 (which is under Tools), you’ll see near the top two possible selection choice: Browser Mode and Document Mode. Let’s build a table of what browser modes can display what document modes.

Now let’s breaks those combinations down. We’ll ignore Quirks Mode in our breakdown below, because we should all have a fairly decent idea of what quirks mode is/does and it should really have much bearing on the current issues.

• IE8 in IE8 Standards Mode is pretty self explanatory, this should be our browser in its happy little normal state.

• IE8 Compatibility View in IE8 Standards Mode – why would you do this? Why is this even possible? Why have they broken my brain already and we’re only on the second option? I mean seriously isn’t the whole point of Compatibility view that it can’t display the page in Standards Mode? Honestly, I have no idea what the results of this combination will be. I have no idea why they’ve even allowed it as a possible combination in the dev tool.

• IE8 Emulating IE7 in standards mode – can’t do it. Selecting IE7 emulation greys out the option for IE8 standards mode, which is kind of what you’d expect for IE8 Compatability Mode if IE7 emulation and IE8 compatibility mode where the same thing.

• IE7 as a standalone browser in IE8 standards mode – again, can’t do it, IE7 is a separate product and this part of the table is just here for consistency (although it does become important later on).

• IE8 in IE7 Standards Mode – surely this should be the same as IE8 Compatibility View? Maybe, maybe not.

• IE8 Compatibility Mode in IE7 standards mode – this is Compatibility Mode’s default, but, as noted above it’s then possible to change Compatibility Mode to render the document in IE8 Standards which seems awfully strange if IE8 Compatibility is identical to IE8 emulating IE7.

• IE8 emulating IE7 in IE7 Standards Mode – again this is the default when you select IE8 emulating IE7 and it becomes impossible to select IE8 standards mode, as you’d expect.

• IE7 Standalone browser in IE7 Standards Mode – this is just the standalone browser doing its thing as you’d expect it to. No big surprises here. Oh wait – yes there are. Turns out that IE8 emulating IE7 is actually slightly different to IE7 Standalone. It’s kind of hard to get a run down on the exact differences from anywhere but Microsoft have certainly said in the past that the IE8 browser has fundamental changes at its core that make it impossible to deliver an exact IE7 experience (which makes sense). On top of that, Microsoft have also released information on how IE8 Compatibility Mode is different to IE7 and that can be found here . What that lovely page doesn’t clarify is if those same differences exist between IE8 Compatibility View and IE8 emulating IE7 or IE8 emulating IE7 and IE7 Standalone.

IE8 Compatibility View does not equal IE7 Standalone Browser
IE8 emulating IE7 does not equal IE7 Standalone Browser
IE8 Compatibility View may equal IE8 emulating IE7 – it seems hard to get a definitive answer, my very strong hunch is currently that IE8 Compatibility View does not equal IE8 emulating IE7, but you’re welcome to disagree. It would help if we ran some tests I guess.

Well, I hope you’ve all had as much fun as I have. I’m now going shoot myself in the head.

Spent the last few days wrestling with what I can safely say is the most obscure bug I’ve ever had the pleasure of trying to track down.

I had a flash player wrapped in a jquery/html/css wrapper that I was embedding in a page that was working fine in my development environment but when I tried to put it on a page with content the flash was failing to embed in all the versions of IE that I tried.

So, I started stripping out content until I got a working player and then trying to figure out what bits of content were actually causing it to fail. Here’s what I found:

• If there was an <img> tag on the page with a src attribute that linked to an external source (ie, http:// followed by even a single character) it would fail.
• If the img src attribute was linked to an internal image it would work fine unless the content also contained an <li> element embedded within a <ul> (it wouldn’t break if the <li> was embedded in a <ol> or if the <ul> was just empty).

As of now, I still have utterly no idea what was going on, but I managed to actually fix it with an ugly hack of wrapping the flash embed section of the code in a setTimeout function going on a theory that IE was looking at other parts of the DOM when it should have been concentrating on the embed.
setTimeout(function() {
swfobject.embedSWF(url,
$container.attr('id'), config.flashWidth,
config.flashHeight, "9", null, flashvars, params, atts);
}, 0);

This seemed to work, as the player now loads fine in IE in all my test environment as well as the live site I first discovered the bug on. It’s been a strange and frustrating few days though and frankly I’d feel a lot better if I knew for sure what on earth was going on.