FireBug showed me that the CSS wasn’t being applied to the elements that it should have been applied to. Hmm. Then I used the “Net” tab of FireBug to see that Firefox wasn’t even attempting to load the external CSS file.

The solution is simple. My @import directive was surrounded by other CSS instructions. Whereas IE tolerates this, the actual W3C spec declares that @import directives should appear before any other CSS instructions, and Firefox honors this restriction.

Thus, my @import directive was being ignored. I moved it to the top of the file and everything started working.

The lessons? Don’t abuse @import directives. Ideally, they should be used only to have a single CSS file that imports several smaller functional CSS files as a means to provide some organization to the CSS. I was using @import mixed in with my other CSS instructions, which is not ideal.

Here is an example of a function that could duplicate the slowdown in IE. It could be attached to the onkeyup event of the username field. It will provide immediate feedback by altering the class name of the field's container when criteria are met (in this case, the value being greater than 7 characters in length). Your CSS and HTML can then determine exactly what that feedback will look like.

As it turns out, the slowdown in IE is due to a general slowdown that IE experiences anytime the class name of the element is changed. It may be unnoticeable if it happens once, but when it happens on every key press, it is noticeable. The slowdown only occurs, however, when the class name is changed, not when the value is referenced. So the easy solution is to compare the existing value to the value you want to set, and only assign the class name if it is different.

You might change the function above to look something like this.

This will theoretically improve performance in all browsers, although it is relatively moot in Firefox, as it doesn't experience the same level of slowdown. But for IE, this tweak in your code will make a noticeable speed improvement.

We're using labels to line up form elements like so:

No problem. Everything looks great. Now I'll take that same concept but add some disparity in the heights of the label and the content. For this example, let's use a <div> with multiline content. Let's put borders around the content areas so that we can see what's going on.

Here is the HTML:

Some CSS like this might work:

That should produce something like this:

Oh my. That's not the effect I was shooting for. But look at the green borders of the inner divs. They aren't next to the floated label like I'd expect; they are on top of it, but their content still flows around the floated label, which is why the first example above with the text fields looks fine, but this multiline div reveals the actual behavior the div has when it sits below a floating element.

Right around now is when I'm cursing floats and dreaming of the days of table-based layouts. This behavior is actually intentional though, and once you understand it, it isn't hard to work with. Like the Float Basics page on Floatutorial points out:

A floated box is laid out according to the normal flow, then taken out of the flow and shifted to the left or right as far as possible. Content can flow down the right side of a left-floated box and down the left side of a right-floated box.

That explanation makes the behavior make perfect sense. The label is taken out of the flow, and thus the <div> sits on top of it. Once you understand that, it is easy to see that a left margin or padding will take care of the div's alignment.

This change:

Produces the desired effect:

The final result, without the borders:

Alas, I digress. The point is that IE isn't going anywhere for now, and it is a pain sometimes to figure out how to write CSS that renders as close to identical as possible between IE and other browsers like Firefox. There are several sites out there that endeavor to explain the IE bugs and, when possible, provide workarounds.

Sure, I could just alter the CSS to look right in IE, but if I'm not careful, that "fix" then breaks the code in Firefox! So we've come up with hacks to have CSS that other browsers will see but IE ignores. I don't know about you, but I'm tired of trying to understand and remember these tricks for satiating IE.

Welcome to conditional comments in IE. This is yet another IE-specific feature that we can actually use to our advantage to level the playing field.

Conditional comments are just what they sound like: HTML comments. But these comments are coded in such a way that effectively have a conditional statement in them, and any HTML output within the comments will only be included (by IE) if the condition is true. Here is an example.

As you can see, any non-IE browser will just ignore all the content, since it's really one large comment. But IE recognizes the conditional logic inside the comment and renders the content accordingly.

Here's an example. This box will have a message if you're on IE, and it will be blank if you're in any other browser:

If you wanted, you could use this technique to inject HTML elements specifically for IE.

Yeah. If you want a maintenance nightmare. Do not sprinkle conditional comments in your code.

Rather than having a CSS file littered with IE fixes (or just accepting the variances between IE and Firefox), I would much rather have a single "clean" stylesheet file that is then augmented by an IE-only stylesheet, loaded by IE and ignored by all other browsers via the conditional comments feature.

So, perhaps you might have some code like this in your header:

There is still a very real danger here. You don't want to fall into the tendency to write intolerant CSS that needs a lot of "cleanup" to look good in both browsers. Work hard to make your CSS as compatible as possible, and leave the ie.css file exclusively for the rare cases where you could not resolve an inconsistency in IE. When you're done, your ie.css file should be really small, if you require it at all.

Having said that, however, I think this is a graceful solution. You don't sacrifice the consistency of your HTML nor your CSS, and your only extra work is the tweaking done in your IE stylesheet. Other solutions like Targeting IE Using Conditional Comments and Just One Stylesheet over at PositionIsEverything.net recommend adding an IE-specific div tag around your content, which would enable you to have a single stylesheet and to not just include IE-specific styles but also exclude certain styles from IE. Unless you have some CSS that you just can't tweak for IE and you have to exclude it, I definitely prefer the simpler approach of just including a secondary, corrective stylesheet and leaving the HTML alone. But that's just the purist in me.

And once you do, you can reference this awesome Scriptaculous Cheat Sheet designed by Amy Hoy of Slash7.  She did a great job at covering the basics, keeping it simple.

Okay, so I stole the dancing line from Tom Yager. But only because it is so hillarious and yet appropriate. I plan to continue using that line.

But what I'm so excited about is an absolutely awesome site called 24 Ways. This is a great site to take the average Joe Developer and transform him into a web demigod! I haven't had a chance to read the articles closely yet, but they cover a wide span of topics (from CSS to DOM to AJAX and beyond), and the articles have great links to other sites that are just as rich in great lessons and examples in modern web development.

It's enough to make my geeky heart skip a beat.

Check out this article:
eWeek: CSS Support Could Be Internet Explorer's Weakest Link.

As the title of this post clearly indicates, the answer to that question is, "No." In fact, Microsoft is arguably taking the worst action possible: They will alter (read: "enhance") support for CSS2, but not fully support it at this time. If you still won't be supporting this very important standard, wouldn't it be wiser to just leave your support how it is? Think of the consequences; your alteration to your CSS support will force developers to update code for their sites if they want to keep them clean in IE (which every developer should do, since IE users still represent the majority of web traffic), yet the updates will serve no purpose other than to maintain compatibility with Microsoft, rather than the more noble--and thus more acceptable--purpose of delivering CSS2 compliance to their site.

Thus, when Microsoft finally decides to fully support CSS in IE, developers will be forced to update again.

And the reason for Microsoft's reluctance? According to sources, Microsoft considers CSS2 a "flawed" standard. Sorry, Microsoft, but between IE and CSS2--even if CSS2 is flawed--I'll take the lesser of two evils.