Your browser is not supported.

I am reminded, forcibly, why I hate to program in PHP. It’s made doubly worse because I’ve spent the last few months steeped in Ruby and Python, which are so much better it’s almost—almost—laughable.

So you may have noticed the new template. What you may not know is that the changes are more than skin-deep: I’ve rewritten the template from the ground up to take advantage of all the latest CSS3/HTML5 bells and whistles, including my new favorite thing, Compass.

The site is now responsive: you should be able to look at it on everything from an iPhone to a desktop and the layout should gracefully change to accommodate the screen size (if you notice any wrinkles, please do let me know).

Finally, the site design makes use of a series of best practices that my colleagues and I have been compiling over the years, which has culminated in an open source project we call our CSS3 Foundation.

Take a look and let me know what you think!

So you may have seen me mention before how, every day since I wrote this post about a workaround for the IE7 z-index bug, it has accounted for anywhere between 25 and 50% of my traffic.

Which is cool, don’t get me wrong. But when I was checking out my site statistics this morning, I realized that one of my more recent visitors, going to that post, was coming from the microsoft.com domain, meaning that s/he is a Microsoft employee.

Oh, the irony is simply delicious.

Update 2009/09/12 09:19—The jQuery version of the dynamic z-index function has been optimized to use hover instead of mouseover/mouseout. Thanks to commenter Eric Conner for pointing out my mistake.

Update 2009/08/04 22:22—The jQuery version of the dynamic z-index function has been added.

Update 2009/07/09 10:52—The code has been updated to make use of the latest innovations in the Prototype library, and to take suggestions from commenters into account.

Now that we’ve officially transferred support of our big application from IE6 to IE7, I’ve been spending more and more time delving into the nitty gritty details of making that hugely complicated layout (recently made less complicated, but that’s another blog post) work in IE7.

I had thought, initially, that IE7′s superior CSS support would make my life a lot easier, and it did in some ways: my IE7-specific stylesheet is a fraction of the size of the IE6-specific one, and the ability to use attribute selectors is huge for me. But as I should have expected, I just traded one set of headaches for another. While IE7 is far superior to IE6 in terms of CSS support (and far inferior in other ways, user interface chief among them—but that’s another blog post, too), the bugs that still exist are more subtle and far more difficult to work around.

The IE z-index bug had been around since IE4 or 5, and was finally fixed in IE8. It’s still an issue in IE7, however, and chances are that you, the web developer, still have to support it. You should read Aleksandar Vacić’s in-depth characterization of the problem to really understand what’s happening, but what it boils down to is this: the CSS 2.1 spec says that a positioned element with any integer z-index value (i.e. not auto) should create its own zero-based stacking context, and use the integer value specified to decide its place in its parent stacking context. In other words, if the positioned element has a z-index of auto, its stacking context is inherited from its parent. Internet Explorer, however, creates a new stacking context for elements with any z-index value, including auto, which wreaks all kinds of havoc and generally causes mayhem in your previously neat and orderly layouts.

(more…)

that no one will be as excited about this as I am, but I’ve just rewritten my theme to take advantage of the sidebar widgets plugin. What does this mean? It means that I’ve made my sidebar dynamic, such that I can drag-and-drop different sections onto or off of my sidebar, reorder them, etc. without actually having to touch the code. If that wasn’t cool enough, now I can also use other people’s widgets on my site. Nice.

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.

First, let me make my excuses. As I have said before, I’m self-taught on all this web development stuff, so what I know is usually what I have had a need to use. Which means that sometimes I don’t discover features of the standards that would have been useful to me until pretty late in the game. And that is exactly what happened to me a few weeks ago with the inline-block display property.

Usually when I needed to give an inline element dimension and margins, I would give it a block display and float it to ensure shrink-wrapping of the content. But adding the float would bring its own host of issues to deal with, especially in IE, meaning that doing so was always a headache. So when I discovered the answer to my problems, in the form of the inline-block property—it allows you to give dimension to an inline element as if it was a block element, but it still lays out, and shrinkwraps, as an inline element would—I was ecstatic, for all of the few minutes it took me to discover that Firefox ≤2 doesn’t support inline-block.

So I did some searching, and all I could find on the topic were a few blog posts bemoaning the lack of support, or newsgroup posts asking for help on the subject. Then I came across a potential solution: the proprietary -moz-inline-block property, which was seen by Firefox and ignored by all other browsers. So I tried it, et voilà…it still didn’t work. Firefox seemed to be treating it as a block property; that is, it was forcing a line break afterward. Which didn’t solve my problem at all. After some more searching, I found that I wasn’t the only one having that problem. Back to square one.

More searching. Then I found what I thought was it: the -moz-inline-box property, which is actually supposed to behave like inline-block^*, even though -moz-inline-block, which has the same name as the property I want, doesn’t. Huh?

Nevertheless, I tried it, and it worked. But, and by this point you won’t be surprised, in only one case^**. The rest of the time, it made my content disappear entirely, or didn’t have the right dimensions, even though I had given those elements fixed widths in my stylesheet. Conclusion: Firefox’s support of inline-block is minimal, buggy at best. It’s best to act as if the property is not available at all.

So what did I do to solve the problem? Pretty much what I had been doing before. I left the element displays as inline-block (for Safari and IE, which support the property) and -moz-inline-block (for Firefox), but added float: left to make it all lay out properly. After all that, I had gotten precisely nowhere. Yeesh.

Despair not, though, gentle reader. Apparently there is a light at the end of the tunnel.

^* In most cases. As I found out today.

^** My theory on this is that -moz-inline-box will only work on elements with both a fixed height and width. Making it kind of useless in the long run.

Update 2008-07-03 13:04—Firefox 3, as I’m sure you know by know, supports inline-block, so the good news is that you only have to worry about your Firefox 2 users.

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.