I was working on a web app a couple weeks ago when I hit a weird problem. I had a sidebar floated right, and an unordered list right next to it. What was weird is that each list item was getting “pushed aside” by the floated sidebar. This went against what I thought I knew about how floats work in CSS. My understanding was that floats should be removed from the page layout, and appear above any other block level elements, like my list items. Reading CSS Float Theory: Things You Should Know and the W3C spec on floats only backed up what I thought. Floats should always appear above block boxes, like LIs. I wrote up a minimal test case and tried it out. What I expected was something like this, where the green boxes are LIs, the red box is my floated DIV, and the purple box is a normal block element like a P:
Instead, what I saw in Firefox 2 was:
It actually took me a very long time to get to this point because I hadn’t even bothered to try it out in non-Firefox browsers, since I assumed Firefox was right and I was missing some arcana in the spec. I had tried it out in Internet Explorer 6, but I had taken that as even more evidence that Firefox was right (if it differs between IE6 and Firefox, it’s usually IE6 doing it wrong). However, when I finally popped my test case into Safari 3 and Opera 9 and they agreed with IE, I realized that it was really a Firefox bug. Not too much searching later I came across this css-discuss post which pointed out the bug and offered two solutions. Either I could force my LIs to take up the whole space by setting “width: 100%” on them, or I could use the proprietary Mozilla CSS property “-moz-float-edge: content-box“. Either one made the list items act like I expected them to, though you give up some flexibility with the first method, and the second won’t validate.
This bug has been filed as Bug 163110 since August 2002, and many duplicate bugs or similar-but-not-quite-duplicate bugs have been filed since. Unfortunately, it doesn’t look like anyone is working on fixing it, and I don’t expect to see this problem go away in Firefox 3, which should be shipping relatively soon. I’m just going to have to add it to the list of bugs and workarounds I need to keep in mind whenever I’m navigating the minefield of modern web design.
Update (5/29/08): This has been fixed as of Firefox 3 RC1. Yay!
Tags: 
Entries