IE5/Mac Annoyances

Some years back MicroSoft did an amazing thing: they developed and released a version of Internet Explorer for MacOS. They embraced the Enemy, though it was hardly an altruistic move, merely part of their strategy to crush Netscape once and for all and to establish a toe-hold in the Mac world. But ulterior motives aside, IE5/Mac was a spiffy bit of software that blew the pants off Netscape 4. Lightweight, smooth, usable, it introducing real font scaling and remarkably innovative support for these new-fangled web standards, including an up-and-coming thing called CSS.

But with all innovations there must come a stack of obstacles. First off is the fact that IDs and class names are case-sensitive in IE5/Mac. The official spec from the W3C clearly states that the case-sensitivity of IDs and classes is reliant on the sensitivity of the page language. For example, HTML4 is not case-sensitive, while XML (and thus XHTML) are. So you should be able to define a class as “BigText” in your style sheet and refer to it as “bigtext” in your HTML4 page without any issues. Not so in IE5/Mac. Your pages have to call the classes exactly as they are defined or they’ll simply be ignored. No big deal if you’re careful with your code, but it can be quite vexing when you work in a development team with some old-school MSDN folks who are used to all-capped tags and first-letter-capped attributes as Visual Studio renders them.

Then there are the CSS bugs. Not a lot of them, and certainly not nearly as bad as the CSS bugs in IE for Windows. But still enough to be annoying. I encountered two such bugs today, both in completely different areas, and both on pages that have been in production for quite a while on a well-trafficked e-commerce site, and had gone unsolved until now.

Bug Number One: Acne Crashes

Our brand name is a registered trademark, and as such needs to always appear with the little ® mark next to it. However on pages where the name can appear dozens of times all those little circled Rs start to look like zits on a supermodel. They’re required for legal and branding reasons, but are quite unattractive, so I tried to minimize their impact by wrapping them in <sup> tags, then used the following CSS:

sup { 

    font-size: 8px;

    vertical-align: text-top;

    color: #ccc;

}

Thus making them tiny, aligned to the top of the surrounding line-height, and medium gray. This worked like a charm until they needed to appear in a box with a creamy orange background color. The light gray lacked enough contrast, and they simply looked like whiteheads instead of blackheads. Enter a new bit of CSS:

.colorbox sup {

     font-size: 8px;

     vertical-align: text-top;

     color: inherit;

}

The class “.colorbox” carries the orange background color, and any superscript appearing within it will inherit the foreground color. Seems simple enough and worked a treat in every other browser tested. Yet for some reason that particular page was crashing IE5 on the Mac. Numerous developer man-hours were spent debugging that page before my co-worker finally narrowed it down to one bit of code and asked for my help as the resident CSS guy. After a bit of trial-and-error and some Googling we discovered that it was a manifestation of a known bug. The description of the bug says the combination of vertical-align and inherited background causes the browser to crash, yet evidently it works on inherited foreground colors as well. Simple to fix (just replace “inherit” with “#333”, the foreground color of the colorbox class) but quite aggravating to discover.

Bug Number Two: Sparring Floats

We have a page with a series of pretty boxes, built with lots of complex nested tables (I must sheepishly admit that I built it about a year and a half ago, I’d do it quite differently today knowing what I know). Each box has a title bar which consists of text in a <td class="title"> and at the far right of each bar is a link back to the top of the page. To get these two pieces (the title and the link) to live at opposite ends of the bar I used a pair of spans:

<span style="float:left;">Title Text</span>

<span style="float: right;">Link to top</span>

Once again, this is perfectly valid and legal code (if a bit sloppy) which works in every other browser tested. But in IE5/Mac the page hangs completely and freezes the browser, requireing a force-quit.

More developer hours spent debugging and isolating the title bars as the cause of the problem. Floating the link to the right and allowing the table’s natural left-alignment to take care of the title worked perfectly in IE/Mac. However in most other browsers the link gets pushed onto a second line, which is unattractive because it adds height to the title bar. The solution this time was less obvious, and more shameful. In the interest of expediency to get this bug closed in time for an upcoming release, I actually…. um…. nested another table.

The title bars now consist of a parent <td> containing an invisible two-column table, with the right column aligned right. I’m not proud of it, and when I have the time I’ll fix it the right way, but for now this does the trick. Under deadline pressures I was forced to sully my code, all because Internet Explorer 5.2 for Mac OSX just can’t jive with a little bit of valid CSS.

It’s getting to the point where IE for the Mac is almost as frustrating as IE for Windows. And like older versions of IE for Windows, there will still be plenty of users out there hanging onto their outdated browsers for years to come, forcing us to keep hacking around their quirks.