Flipping through my archives, I noticed that I haven’t really spoken a lot about Internet Explorer app compat. Since moving people off of IE6 to IE8 is a pretty big corporate priority right now (trust me, the grass really is greener over here), I figured I’d walk folks through a debugging session I was doing earlier today to give some sense of how to approach these issues.

My (not necessarily representative) anecdotal experience is that the problem space for moving from IE6 to IE8 is quite a bit smaller than the problem space of moving your Win32 apps forward (particularly going from admin Windows XP to non-admin Windows 7), but there are fewer people who know how to do it. I guess that’s what happens when you spend 3 years teaching people about Win32 apps, but IE apps just get an occasional mention – pretty soon, what started out as the small problem you didn’t need to spend as much time on becomes the big problem you haven’t addressed yet.

Now, the challenge of writing about a real, live web site is that the web authors could very well come along and fix their site before you have a chance to see it (particularly if they’re reading this) – so, if you’re reading this a ways down the road, you probably won’t be able to see the issue. I’ll try to describe it really well.

If you go to http://www.nodepression.com/profiles/blogs/our-top-10-alltime-favorite you will (may?) find a post with a number of web links to videos shown on YouTube. Somebody reported that this failed on IE8 but worked on “Chrome/etc”. What happens is, if you try to click on one of the links, you can’t – it scoots away. Wow – that’s pretty annoying! So, let’s figure out why.

First, I want to get a sense of what’s happening. It could be something in either the CSS or in a script. So, I pulled open my F12 debugging tools to have a look. Using the “Select element by click” tool, I clicked on one of the links, and zoomed straight to the <a> tag in the HTML. It has an href attribute, and no scripts attached. So, my initial hunch is that there is a problem with the CSS, and not with a script. (Note: I could have tested this hypothesis by disabling scripts and trying again, but I was feeling confident and in reality just skipped this test.) I was at this point just looking for styles that applied to A tags.

I found several in http://static.ning.com/nodepression/instances/css/theme_1280787484.css – and most of them I was unfamiliar with. I’m not a CSS ninja by any means, but I am pretty handy with a web search engine. So, I started inquiring about all of the modifications to this tag. I stumbled upon the :active Pseudo-class, which has been around since CSS 1. An action is being performed, but is not yet complete. And that’s exactly what we’re seeing – we mouse down, and it’s at this point the link runs away from us. Looks promising, so let’s dig in.

If we look through the CSS in this stylesheet, we do spot something curious. It specifies float : left. Aha. So, when you click the mouse down, the CSS is directly instructing the browser to move “left or right until it reaches the border, padding, or margin of another block-level object.” You know, exactly what it was doing when we clicked on it. I think we have our culprit.

The magic of the F12 debugger tools allow us to confirm this hunch. Simply uncheck this CSS attribute in the CSS pane of the debugger tools, and now try it. Voila! The link stops jumping away, and you are able to click on it now! This is not a compatibility bug in IE, it’s a bug in the app!

Of course, the report mentioned that “Chrome/etc” worked, so it was time to pull out my other browsers and see what the story was there (since technically they might not be implementing CSS 1 – reminder, I am not a CSS ninja so I might be mistaken).

Internet Explorer 6 – App fails

Internet Explorer 8 – App fails

Firefox 3.6.8 – App fails

Opera 10.60 – App fails

Safari 5.0.1 – App works

Chrome 5.0.375.125 – App works

So, in this case, apparently “etc” means “Safari” – and since the app working is essentially the browser not doing something I believe the CSS 1 spec suggests it should be doing, this was just luck that an unimplemented bit of functionality in the browser matched with some perplexing CSS in the app.

So, the case was closed. This isn’t an IE8 compatibility issue, it’s a genuine bug in the app, and the poor browser is just doing what it’s told (and, in this case, it’s told to do something pretty silly). And, according to this, it’ll be broken for 86.1% of the world.

Internet Explorer 8 – 1; App – 0. :-)