Just Like IE

Introduction

"Make insert-name-of-non-IE-browser-here work just like IE."

That's the common (and unfortunately, naive) request by people who download a new browser and find it doesn't handle all web pages the same as Internet Explorer does. It is, of course, an entirely understandable request. Who wouldn't want every page on the Internet to just work?

The problem with making web browsers work just like IE is this: how does IE work in the first place? The truth is, nobody knows, not even Microsoft! Very few software developers know in detail exactly how their software works. In particular, they generally don't know anything about how their software operates in relation to bugs. After all, if the developers knew their software had bugs, they would have fixed them. The behavior of bugs is, therefore, completely unknowable.

This causes problems when web page developers code their web pages to depend on IE bugs, often unknowingly. In order for other browsers to render their web pages "correctly", the other browsers have to know what bugs the page in question is depending on and how they work.

Float Nightmares is a blog article by David Hyatt, the developer of Apple's Safari web browser. In it he describes the almost random behavior of Internet Explorer in certain circumstances. How (and even why) anyone would want to make their browser just like that is beyond me.

Handling of Author Mistakes

A Simple Typo

A site was drawn to my attention that looked wrong in Opera, but OK in IE. The problem turned out to be a section of text that didn't break and extended beyond the right edge of the screen. The reason it didn't break was due to a mistake in the source code. The page used the non-standard <nobr> element, and a closing tag had been mis-typed ("bobr"):

Lorem ipsum <nobr>dolor sit amet</bobr>, consectetuer adipiscing elit. <nobr>Etiam varius dui</nobr> quis justo.

The problem was the difference in how the two browsers handled that mistake. Both browsers ignored the mis-typed closing tag, so the text following it was still considered part of the non-breaking text. However, when the browsers got up to the next <nobr> element, IE decided that having a <nobr> element inside another <nobr> element didn't make any sense, and closed the first <nobr> element before proceeding to handle the next (non-breaking text is red):

Lorem ipsum <nobr>dolor sit amet</bobr>, consectetuer adipiscing elit. </nobr><nobr>Etiam varius dui</nobr> quis justo.

Opera, on the other hand, decided a <nobr> element inside a <nobr> element was fine, with the result that all the text that followed was in a <nobr>:

Lorem ipsum <nobr>dolor sit amet</bobr>, consectetuer adipiscing elit. <nobr>Etiam varius dui</nobr> quis justo.

Lack of Documentation

Which browser handled the mis-typed closing tag correctly? Reading Microsoft's documentation on the <nobr> element does not reveal any information relevant to nesting. It doesn't say whether or not the elements can be nested. Since the nesting behaviour isn't specified, both browsers are doing the right thing!

Given that the nesting behaviour isn't documented, how was Opera to know that IE in actual fact does not allow nesting? Only by testing. There are 98 elements listed in Microsoft's documentation. Opera would need to test each element. Then how each element interacts with every other element. Already that's nearly 10000 tests! More complex interaction involving three elements is nearly 1 million tests! Testing is obviously totally impractical. (Eric Meyer, CSS guru, has had a little to say on the subject of testing, too.)

In this specific case, IE's handling of the mistake ended up being closer to what the author obviously intended than Opera's. Does that mean IE is always better? No.

A Counter-Example

Consider the following:

<nobr>Lorem ipsum dolor sit amet, <nobr>consectetuer adipiscing elit</nobr>. Etiam varius dui quis justo.</nobr>

This time the entire text is inside a <nobr> element, with a portion of one sentence also enclosed by a nested <nobr> element. This time there are no typos and the author obviously wants the entire text to not break. How do the browsers handle it? IE, as before, closes the first <nobr> when it encounters the second. The last part of the text is outside the non-breaking area, contrary to what the author wanted:

<nobr>Lorem ipsum dolor sit amet, </nobr><nobr>consectetuer adipiscing elit</nobr>. Etiam varius dui quis justo.</nobr>

Opera, as before, doesn't close the first element, but instead allows the nesting and therefore the entire text is enclosed in a non-breaking area, just like the author wanted:

<nobr>Lorem ipsum dolor sit amet, <nobr>consectetuer adipiscing elit</nobr>. Etiam varius dui quis justo.</nobr>

It's the same element, the same rules. Opposite outcomes.

What's interesting is that Opera's behavior in the first example would have drawn the authors attention to their typo. IE hid the authors mistake, leaving it there to cause problems later on. And in the second counter-example, Opera does what the author intended and IE didn't. In both cases, Opera's behavior is objectively the better.

The Real Problem

This shows that no browser's error handling is any better than the other's. Whenever a browser has to guess what the author intended, inevitably they're going to guess wrong.

So, why does IE seem to get it right more often? It probably doesn't. What's happening is that web page authors are checking their pages in IE and fixing any problems they see. If they don't also check in other browsers then any problems those browsers show won't be fixed.

The idea that IE handles mistakes better is simply an illusion created by web page authors testing only in IE and cleaning up its mistakes, while not making any effort in relation to other browsers.

The Solution

Test, test, test. There is no other way. Wherever specifications are unclear, wherever important information is missing (such as how to handle nested <nobr> elements), browser developers have to make a decision on how to handle the situation. Inevitably, different developers will make different decisions.

Different developers will also make different mistakes. All browsers have bugs. The only way to ensure web pages are not affected by different interpretations or bugs is to check them in as many browsers as possible.

Web page authors who only check their work in one browser are going to produce pages that tend to only work in that one browser. Eventually they will do something that causes problems in those browsers they aren't testing with. It doesn't matter which browser they test with; it could be IE, Firefox, Opera or Safari. One browser is not enough. Without broad cross-browser testing there will always be cross-browser problems.