meyerweb.com

In creating the combo-bar charts for the survey report, I stumbled into an Explorer bug that I didn’t remember ever seeing before, and Google didn’t turn up anything that seemed to be related. This could easily mean that I’m the only person who ever did something this insane and thus found the bug. It could just as easily mean that my Google-fu has failed. Either way, I’ll write it up here so it can enter the collective memory. (And surely someone has already noted that Google is positively Jungian?)

You can see both the problem and two workarounds if you visit this test page using IE6 or IE7. In brief, the problem occurred when I had a table cell containing a paragraph with an explicit width set. I did this through the style attribute, though tests show that for this bug, it doesn’t matter whether you use the attribute or assign it via a style sheet. Around these explicit-width paragraphs were div elements with width: 200%;, for bar-drawing purposes (it’s a little complicated). Everything was fine in 99% of cases. But as soon as the header text at the beginning of the row went to two lines of text, the explicit-width paragraphs doubled in width. What was 80.1% wide would be drawn as though it were 160.2% wide.

My hopefully understandable reaction was to say, “Whuh?”. I threw a few hasLayout triggers at the offending paragraph (relative position, zoom, etc.) and got nowhere. In the end I worked around the problem by telling IE6 and IE7 to not wrap text in the row headers of combo charts. (The bug is not present in IE8.)

I mentioned all this in my announcement post, and the ever-awesome Dan Wilkinson discovered that the problem could be fixed by setting all of the table rows to, say, height: 3em. Armed with that breakthrough, I experimented a little more and found that I could actually set the offending table row’s height to 2.75em and still have things work as intended. Below that and the paragraph widths doubled.

Then I lowered the line-height of the headers to 1 and found that I could take the overall row’s height as low as 2.33em before triggering the bug. And that’s when it dawned: the bug was triggered by the layout height of the header cell’s content being taller than the content of the cell containing the paragraph, and not explicitly declaring styles that would make the data cell as tall as or taller than the height needed to have the header cell contain its content.

Okay, that’s a little dense. Let me step through the symptoms and two found workarounds to see if that clears it up:

1. The data cell always has a single line of text. The bug is triggered by having the header cell go to two lines of text, whereas it is not if the header cell has a single line of text.
2. If the row’s height is explicitly set to a value equal to or greater than the header cell’s content, the bug is not triggered.
3. Alternatively, if the height of the data cell is set or forced to be equal to or greater than the height of the header cell, the bug is not triggered. This can be done with an explicit height or with added top and bottom padding or by adding top and bottom margins to the paragraphs in the cell.

Some side tests I did indicate that the header cell is not needed to trigger the bug. In other words, the problem could happen even if there are only data cells in the row. Furthermore, I found that the width-scaling was directly affected by the width of the wrapping div, and thus the widths were doubling only because I had the div’s width set to 200%. If I set it to 150% instead of 200%, then the paragraphs only got half again as wide instead of doubling. That seems to make sense until you see it in action. When I say the paragraphs got half again as wide, I mean that instead of being 75% as wide as the div, they were 112.5% as wide as the div. If I set the div’s width to 200%, then they were 150% the width of the div.

So. As I say, this bug does not affect IE8, so that’s good, and it can be worked around in IE6 and IE7, which is even better. The problem would be if you didn’t know how tall your cells might get—in my case, I can be (reasonably) sure that the tallest a cell’s content will ever get is two lines of text, and by setting an explicit line-height on the headers I can know how tall I have to make the rows in order to avoid the bug.

Another day, another workaround!