Your browser is not supported.

IE6 Denial Message for Momentile.com

(via DF)

Any halfway successful project is a significant learning experience, and the one we just completed at work was, bar none, the most challenging I’d ever faced. Because of the incredible complexity^* of the UI we were trying to implement, I had to empty out my bag of tricks, and then find new ones to add to it. Quite aside from the innovations in design and implementation I perforce became familiar with, though, I fought a pitched battle with IE6.

It seemed that at every turn I was thwarted by some IE quirk, and I had to fix each problem as I found it; success was my only option. So I built up my little arsenal, and went to it. What follow are the biggest issues I faced in making the site IE6-compatible, and how I worked around them. They are not the only issues there were, but they were the most common, and are IMO the most important to keep in mind when developing any new site for IE6.

• Problem: Floated block elements that have a fixed right or left margin will show up with that margin doubled.
  Workaround: Give the floated element a display of inline.
  cf. Doubled float-margin bug.
• Problem: Block elements containing both floating and non-floating elements may have some or all of the non-floating content overdrawn by the background, making it appear missing.
  Workaround: Several options here:
  • Give the block element containing the floated element a fixed height or width: a height of 1% is a favorite (this is known as the “Holly Hack“, and is the preferred solution to the problem). Note that IE will disregard the height specification and increase the size of the container to fit the content anyway.
  • Assign a line-height to the containing block element. Any line-height will do.
  • Give both the containing and floated element position: relative.

  cf. The peekaboo bug.

• Problem: Buttons in IE seem to have an excessive amount of left and right padding outside the text, but manually changing the margin or padding properties seems to make no difference.
  Workaround: Override the padding to the desired values, give the button a width of 1px (or something likewise small) and set the overflow to visible. If the fix is not placed in a conditionally included IE6-specific stylesheet, give the button a width of auto and an overflow of visible.
  cf. Button width in IE.
• Problem: Even though you think you’ve removed bullets from your unordered list by giving your ul list-style: none, the bullets still show up.
  Workaround: Use list-style: none none instead.
  cf. Some forum post somewhere; can’t remember. This one might be it.
• Problem: Using Prototype’s built-in getElementsByClassName function is doubling or tripling page load times in IE6.
  Workaround: Use an optimized version.
  cf. The ultimate getElementsByClassName

^* No, really. For this one project, we used what seemed like every modern UI widget in existence: multi-column layouts, tabbed interfaces, flyout menus, drag and drop lists, you name it.

If you’ve worked on any projects as a web developer in the past few years, chances are that what you worked on relied rather heavily on JavaScript and AJAX. And chances are that you discovered, just as I did, that, in addition to all of the CSS headaches you have to deal with when developing for IE, you’ve got a whole slew of IE-related JavaScript headaches, as well. Even leaving aside the little IE-only DOM quirks, you’ve got a big problem still: IE’s flat-out terrible JS performance.

I mean it. Terrible. On one of my most recent projects at work, a Java-based, heavily JS & AJAX-reliant web-application, we discovered that our page load times in IE were anywhere between two to ten (!) times as long as those in Firefox. Which was, obviously, unacceptable, especially given the fact that the app’s user-base is comprised almost entirely of IE6/Win users. So what was I to do? Optimize, of course.

On my quest to find how to optimize my JS to run faster in IE, I came across these great articles, straight from the horse’s mouth, on how to do it:

• IE + JavaScript Performance Recommendations – Part 1
• IE + JavaScript Performance Recommendations – Part 2
• IE + JavaScript Performance Recommendations – Part 3

Unfortunately, while they were certainly illuminating, these articles didn’t do much to solve my problem. Their recommendations, such as caching DOM lookups, weren’t much help to me when I only needed to do those lookups once.

After that, I thought briefly that part of the reason the page controls were taking so long to become available was that the onload event was being delayed due to images loading on my page, thereby causing an overall delay in total page-load time. And I found this nifty method to kick off window.onload after the DOM has loaded, but before other things like images finish loading.

As it happened, though, that didn’t make a bit of difference with my particular issue. What was causing the problem—as I found out after using the brute-force method to comment out all the code in the offending JS function, then adding it back in line by line to see what broke the performance camel’s back—was that using Prototype‘s built-in getElementsByClassName function was doubling, or tripling, or worse, IE page-load times. Especially since I called it in 2 or 3 different functions, all of which ran at window.onload.

So I needed to get (or, god forbid, write) an optimized getElementsByClassName function. Luckily, though, I was spared that horrible fate, because I found the Ultimate getElementsByClassName, courtesy of a guy by the name of Robert Nyman. In a fit of desperation, I added this to my JS library and changed all my code to call it instead of Prototype’s version. Et voilà: just from that one change, I had quadrupled (quadrupled!) my JS performance in IE. Pretty amazing.

Update 2007/10/24 1453: I recently ran into a similar problem again, where page load times, particularly for large pages, were up to 10 times slower in Safari than Firefox, and 20 or more times in IE. The problem was eventually traced back to the use of the Prototype double-$ lookup for CSS-style selectors. The solution? Just don’t use it. It might take more code to find the item you’re looking for, but the performance gain you get from not using the $$ lookup is worth it.

Making your site work in IE
So there you are, with a good understanding of the standards, armed with some great CSS UI conveniences, and a snazzy prototype. But then you fire it up in Internet Explorer 6 for Windows, and it all goes to hell. You’ve got unnecessary horizontal scroll bars, magically disappearing and reappearing content, and list bullets where you don’t want them. Mysterious extra right and left padding, odd positioning, and static content that jumps when you hover on a nearby link. Problems galore, and you’re ready to tear your hair out. (My colleagues say that they know when I’m working with IE because I start swearing at my computer.) It’s inevitable, really.

But cling to hope, gentle reader, because you’re not the first, and, I am confident in saying, not the last to have these problems. In fact, most of the problems you will encounter have already been found—and solved. But before I get to that, let’s discuss the problem of how to hack your CSS to work in IE such that it’ll degrade gracefully when your users inevitably upgrade to IE7.

Up till now, there have been a number of ways to create blocks of your CSS that are only visible to IE, but they’re, well, hacks, and can’t be trusted to work forever. The best way to add IE-specific styling, I’ve found, is by using conditional comments and an entirely separate stylesheet.

OK. Moving on. Now you know how to add IE-specific styling to your app, let’s find out what that styling should be. You’ve got a passel of problems, but no idea how to solve them. Where do you go for help? You go to the Bible: PositionIsEverything’s list of Internet Explorer bugs and their workarounds, if there are any. Another great article on the subject can be found at CommunityMX (a mostly subscription-only site, unfortunately): How to attack an Internet Explorer (Win) display bug.

For further reading on IE’s display bugs, don’t miss these articles:

• Internet Explorer and the CSS box model
• On having layout — the concept of hasLayout in IE/Win

Other articles you may find useful:

• Button width in IE, a discussion on how to get rid of all the extra padding IE seems to automatically add to buttons and submit inputs.
• CSS and browser compatibility

With all these tools in your arsenal, you can go forth and battle most all the weird browser bugs out there (more on this in another post) and come out the other side alive and even relatively unscathed.

Browsers and browser-plugins
First, let me explain a bit of my strategy. As I said, I code to the standards and then hack for browser compatibility. My first line of defense is Safari/Firefox, and once I have my styles/layout working in both of those, I move on to IE6. I am not supporting IE7 at this time, because our clients run mostly IE6 and have no immediate plans to upgrade.

The browsers alone are not enough, though. Each needs some kind of enhancement or companion tool to help me debug my CSS code.

• Safari + XyleScope: Safari you know about, and XyleScope, you probably don’t. The latter is the only application of its kind out there, and I really wish it wasn’t; I wish there were versions of it for every browser and every operating system. What it does is use the Safari rendering engine to render any URL you give it, and dissects the styles used in every component. The killer part of this app is that you can select any item on the page by clicking on it, and XyleScope will give you the complete breakdown of styles that apply to it (and most importantly, in which order), its place in the markup hierarchy, and a graphical representation of its box model rendering, the last of which is sometimes priceless. I’d love love love to get a tool like this for IE, the browser with the most weird box model-related rendering bugs, but there just isn’t one that does that for me (more on this later).

  XyleScope does have some shortcomings, though. One is that it only uses the Safari rendering engine, which gives it limited usefulness when testing cross-browser compatibility. The second—and crucial—one is that it doesn’t deal with generated elements very well. So when I’m testing with my webapp running, and much of the content is generated by my server-side code, XyleScope gives up.

• Which is mostly the reason that I use WebKit, the open-source, next-generation, beta version of Safari. It’s got two important advantages over Safari, the first being that it lets you style form elements, which Safari does not (which blows). Secondly, it’s got this awesome (seriously, I can’t say enough about it) “inspect element” feature that will inspect any element in your final page, and give you all the goods on it, from place in the markup hierarchy, final computed style, and a listing, like XyleScope’s, of what styles from your stylesheet apply and in which order. On top of that, it’s got a lovely clean interface that is a pleasure to use (except for the obnoxious scrollbar behavior in the markup hierarchy section, but I’m hoping that’ll be fixed soon).
• Firefox + FireBug: Firefox is my control group. Besides Safari/Webkit, it’s probably the best widely-used browser with regard to standards support. If my site works in Firefox, it’ll (mostly) work in every other browser. As I said, debugging is crucial to my work, so I use the immensely useful FireBug plugin to help me inspect generated elements when testing. Feature-wise, it’s almost identical to the inspect element functionality in WebKit, but it’s a little less stable and doesn’t have as nice of a UI; and really, you can say the same of Firefox in general in comparison to Safari/WebKit. That said, FireBug is an invaluable debugging tool.
• Last but unfortunately not least, Internet Explorer and the IE developer toolbar: IE6. What can I say? Like any other web developer who has ever tried to program for it, I hate it. But most of my users use it, so what can I do? Since most of my debugging takes place in IE6, it was vital that I had some sort of debugging tool, because XyleScope isn’t available for Windows. Enter the IE developer toolbar. Much like the inspect feature in WebKit and FireBug for Firefox, this helps you select elements on your rendered page and inspects them, HTML, CSS and all. My very favorite part of this is the tool that allows you to size your window to any of a set of common resolutions, so you can see just how much your users can see, and design accordingly. I couldn’t live without this, as it makes my job that much easier.

according to this interview with Microsoft’s Chris Wilson, IE7 will be much more standards-compliant than IE6, if not fully standards-compliant. Yeah. I’ll believe it when I see it. (Via Slashdot)

using Internet Explorer over a year ago:

1. No support for tabbed browsing.
2. No support for partially-transparent PNGs.
3. And the big one: incomplete CSS2 support.

As if that wasn’t bad enough, there didn’t seem to be relief in sight. It seemed that the new version, IE7, would only come out with the launch of Windows Vista, and that’s still months off. But recently, IE7 finally went into public beta. WebMonkey has a review:

How Does IE7 Stack Up?

While this list of new features is impressive, the other choices in the browser marketplace still have IE7 beat. True, it’s still in beta, but Internet Explorer 7 has some inherent shortcomings that will keep it from being the browser of choice for absolutely everyone.

First and foremost, there’s cross-platform compatibility. Firefox and Opera are being developed for multiple platforms simultaneously, but Internet Explorer remains steadfastly Windows-only. Second, but equally as crucial, is the fact that Microsoft won’t be able to one-up Firefox’s extensible architecture anytime soon. Firefox’s extension management capabilities, not to mention the wide range of extensions available for both developers and basic users, are practically unbeatable at this point.

Finally, CSS support, while vastly improved since version 6, is still incomplete, with limited support for pseudo-classes and CSS-P declarations. Microsoft promises that it will continue to build in support for CSS elements between now and the official release of IE7. Even with these shortcomings, IE7 is shaping up to be a huge step in the right direction. Though the exact figures are difficult to pin down, it’s safe to say that over 80% of the world uses Internet Explorer right now. Users who’ve been chugging along in their asthmatic installs of IE6 are in desperate need of an upgrade. IE7 gives these users more security and a new level of functionality that they may not even have been aware existed.

We’ll go ahead and predict that millions of new RSS devotees will be born this year solely because of IE7′s built in feed reader. And you’ll be able to nod and smile slowly when Aunt Rita tells you that she doesn’t know how she ever survived without tabbed browsing. That, at least, makes IE7 something to look forward to.

So they’re still not going to have complete standards support. And that’s why I’m not going back. But maybe (hopefully!) programming for IE7 will be easier than for IE6.