<Deep Sigh> Ran in to an old familiar-but-forgotten bug today. Caused by tables, currently inserted into the design unnecessarily by the OSCMS I was using. It has been so long since I’d worked with table-based designs I’d completely forgotten that when you style a table as width: 100% IE/Win decides that you mean more than just 100% of the available content area if you have a floated box. (Technical description for the curious: within a screen-width box a box 275px wide is floated left. The screen-width box also contains another box with a left margin set at 300px. A table within this second box, styled at width:100%, will wait until the floated box has ended before displaying, even though there is no overlap between the display areas of the floated box and the table and even though other content in the box before the table will display correctly.)

So I wasted time trying to figure out what was happening. It wasn’t until I stopped looking at the code I was writing and started looking at the code the CMS was writing that I realized what was happening.

The default in IE for a table is to take all the room it needs, up to the limit prescribed by the bounds of the box it’s in. Dropping the width attribute and settling for the default fixed the problem.

That’s the problem with the argument that claims table-based design is simpler. It’s simpler only because we already know the bugs and workarounds for it. When we don’t know (or when we’ve forgotten) it’s at least as difficult as standards-compliant design.