Your browser is not supported.

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.

CSS tips and tricks
If most of my standards references are found at W3Schools, then most of my CSS tips and tricks references can be found at A List Apart, the best webzine on the industry out there. INJMHO^*. Their design articles and how-tos specialize in clean, reusable and maintainable code, and are usually what I go to first when I want to make sure I’m not reinventing the wheel.

Speaking of reinventing the wheel, my three favorite tutorials from ALA are on three of the most common UI elements: multi-column layouts, tabbed interfaces, and CSS-mostly drop-down menus:

• In search of the Holy Grail, an excellent how-to for making a three-column layout with two fixed sidebars and a liquid center. Update 2007-03-07 14:03—Published recently on ALA, here’s another way of making a multi-column layout with equal height columns.
• Sliding doors, a discussion on how to use the sliding doors technique to make dynamically sized tabs.
• Suckerfish dropdowns, a great way to make (almost^**) entirely CSS-driven dropdown menus.
• Update 2008-06-20 11:04—Conflicting absolute positions is an elegant Javascript-less technique to make a multi-column layout that needs to take up the full browser window.

Everything else is more or less kid stuff, so I’m not linking it here.

Next up: Making your site work in IE.

^* In Not Just My Humble Opinion.

^** Almost because IE doesn’t support the :hover pseudo-class on anything but <a> tags.

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.