Another day, another set of broken behaviour
Of late, it seems I stumble upon another bug every other day, most, of course, in everyone’s least favourite browser. As an aside, is it only I who missed out on the renaming of this product to "Windows Internet Explorer"? Probably — I guess it’s just official recognition of the abandonment of IE for the Mac. Anyway, onto the carnage.
First up, an old favourite: IE6- doubles up horizontal margins on floated elements. I hadn’t come across this in production for a while, but it’s always there lurking, ready to strike. The only notes of interest here are:
The first point means that, for any level of old-browser support, this really needs to be tackled. Even the most extreme ‘functional only’ practitioners will be hard-pressed to accept such broken layouts on IE6.
In terms of a workaround, I’m really torn. The easy, ‘do it and forget it’ fix is to use display: inline, e.g.
.left {
float: left;
display: inline;
}
So long as you remember to include display: inline alongside any float declaration, you’re pretty much sorted. The good browsers will, correctly, ignore the display. IE6- will self-correct its bug and everyone’s happy. But that sits really uneasily with me, especially since I don’t like CSS hacks however intrusive they may or may not be. This fix may seem relatively benign, but I fear for those poor souls who don’t know about it, and see that code in action.
Alternatively, that fix could be isolated via conditional comments. Or, such an IE-targeted stylesheet could even just halve the margins. But conditional comments have their detractors, and this option is certainly a bit more effort.
What would be wonderful would be a CSS-pre-processing system specifically designed to ‘fix’ browser bugs, e.g.
[browser lte IE6][float: !none] { display: inline; }
Of course, I’m just making up my own syntax there, and this is really not much better than plain old conditional comments, but it does feel that little bit closer to attacking the actual problem and feels much more portable. For the moment, though, I’ll have to bite the bullet one way or the other.
I admit it: this was a totally new one on me. That’s probably because I’ve never really had the call to use it in real-life, but that’s not much consolation when the bug affects IE7-. The more I learn just how broken IE’s float model is, even in its most recent incarnation, the more despair I feel.
To summarise, floats are supposed to ‘push out’ subsequent text, but not block boxes. In IE, they push out block boxes too, if said block boxes happen to have a fixed width. So, in the following example, your browser should display two overlapping boxes:
In IE, those boxes appear side-by-side. This can have various other nasty side-effects which are nigh-on impossible to fix. All this proves is that premature optimisation is, indeed, the root of all evil. ‘hasLayout’ is possibly the most pervasive example of the adage; not only has premature optimisation resulted in a monstrous spaghetti-tangle of unfathomable source code, it’s spewed forth a bug list as long as anyone’s arm.
I guess I should count myself lucky I’ve never had to deal with this one in production, but it’s yet another thing to keep obsessive web designers awake at night.
That’s a great idea, David, although I’m still concerned that it modifies the markup unnecessarily. A good addition to the 'arsenal', nonetheless.
Wed 28 Jan 2009 17:47
David Hucklesby said:
Years ago I read "Eric Meyer on CSS." In it, Eric advises avoiding putting margins, padding, and borders directly on a floated element. Instead, add a surrounding DIV with no border, margin, or padding-- float that, and put the element with borders etc. inside it.
Bottom line: one extra HTML element, and a number of avoided CSS hacks.
Not always feasible, of course, but it has saved me many headaches.