North Horizon

Browser Compatibility and the Sanity of Web Developers

19 Feb 2009

Since I’ve decided to get this blog rolling, one of my primary objectives was to ensure a consistent, high quality experience for any platform visitors come from. Obviously, it’s impossible to test the myriad of browsers out there, but I think it’s useful to at least test on the top three engines, namely Trident (Internet Explorer), Gecko (Firefox), and WebKit (Safari / Chrome). I also test on Opera, even though it has little market share. Hopefully I’ll get my traffic statistics going again soon, so  I can prove more definitively that sixty something percent of the ten people who come here use Firefox anyway.

So that leave three or so of you guys using IE. Well, I hate to break it to you, but your browser sucks. It really does. Web developers everywhere have been rejecting Microsoft’s browser for some time now, which has given rise to the healthy market share Firefox has had.

How does this affect you and me, you may be wondering. Well, let’s do a case study on the site you’re looking at right now, since I’m fixing it up anyway. For those of you not using a W3C compliant browser (read: IE), the website is supposed to have some blocks of color of varying height below each of the navigation links, which highlight to orange and a main body text that wraps around the sidebar on the right.

northhorizon-ff<figcaption class="wp-caption-text">My post about hashing as seen in Firefox.</figcaption></figure>

Beautiful. Everything looks just like it should in Firefox, Safari, Chrome, and Opera. But what happens when we look at it in IE?

northhorizon-ie7<figcaption class="wp-caption-text">The same post as seen by Internet Explorer 7</figcaption></figure>

Oh wow. Not what I was going for at all. This is quite common for web developers to experience: write a website and make it perfect for the W3C compliant browsers and then try and get it to work in IE, because in all honesty, IE makes very little sense in terms of expected results. On another project, I instructed the browser to move an object 6 pixels left and 10 pixels down. Firefox was happy to oblige, but IE only moved it 3 pixels left and 8 pixels down.

So what’s going on here at the root, so we can fix it? Well, if you inspect my CSS, you’ll find this tidbit:

#sidebar {
	float: right;
	width: 250px;
	list-style: none outside;
	background: white;
	margin: 0 0 0 10px;
	padding: 5px;
	padding-left: 20px;
}

Most notably, I’m using CSS floats to put the Sidebar on the right. By doing so, I’m instructing the browser to make some space for it and to wrap text around it. IE obviously doesn’t care about my floated div, so it just disregards the instruction. That leaves me in a precarious position. Should I abandon my floats, which lead to nicer, cleaner XHTML in favor of tables because of one non-compliant browser? Of course not! Instead I have a little function that tells me what browser you’re using called get_browser(). The code looks like this:

$browscap = get_browser();
define('IE', ($browscap->browser == 'IE'));
[northhorizon-ie7-fixed](http://northhorizon.net/wp-content/uploads/2009/02/northhorizon-ie7-fixed.png)
The same post in Internet Explorer 7 with my fixes.

This gives me a global constant, IE that allows me to change how the website looks if you’re running IE. With this in mind, I actually insert in a table in the middle of the page to force the sidebar to stay on the right. Problem solved.

As I was doing all this, I wondered if IE8 would give me any relief. I was somewhat surprised to find that it does, in fact, respect floating divs, and even respects the :after pseudo classes that allow me to add those blocks under the navigation links. Just not the hovering. Sigh. Anyway, all I needed to do was modify my IE code to check the major version number of the browser to say that IE8+ was really mostly W3C compliant.

$browscap = get_browser();
define('IE', ($browscap->browser == 'IE' && $browscap->majorver < 8));

So why is IE this way fundamentally? I don’t have any real code or facts to base these assumptions on, but my speculation is based on working with both XHTML and CSS as well as C# / WinForms / WPF. I assert to you that Microsoft has misunderstood the Web since its inception. With things like ActiveX (now, thankfully, deprecated) it seems like Microsoft has always wanted to bring Windows to the web – literally. In Windows Forms (the battleship gray programs we all used to know), each visual element is a very unique item. Buttons don’t behave very much like Panels which don’t behave very much like CheckBoxes. It follows that you can’t really apply properties that relate to a Button to a Panel. Sensible enough. Unlees you’re dealing with XHTML and CSS. Back when XHTML went 1.0, I was somewhat surprised to see that they had actually removed elements and attributes from the specification. Usually, moving to a new product means that you get more, not less. It took some time, but I eventually realized that the Web isn’t like WinForms at all. Each element on the web (with the exception of form controls like ComboBoxes and CheckBoxes) is really the same. Almost everything can be broken down into a div or a span, and really if you change the display attribute on them, you end up with one amorphous panel.

This is the fundamental difference between IE and the W3C triad. Microsoft insists that floats and hovers really shouldn’t apply to things like divs, because they come from two seperate branches in the object tree. Really, until Microsoft realizes this, throws the existing codebase out, and tries again, IE will never be able to keep up with the rest. It’s a matter of understanding the nature of the Web and using an appropriate architecture to interpret it.

Related Posts