Handling an Explicit-Width Bug in Internet Explorer
Published 15 years, 4 months pastIn 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:
- 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.
- 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.
- 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!
Comments (9)
“ever-awesome”?! You’re too kind! Nice explanation of exactly what was going on here…and again, wonderful work on the survey as a whole.
Wow. I’ve never seen or heard of that one before either?! IE really is the gift that keeps on giving eh?
That’s why we should Save IE6.
Just when you think you’ve found them all already…
Thanks for the write-up! This serves as a great example of how web developers should be approaching bugs when we come across them. Experimentation followed by documentation.
When I saw your post I was hoping you’d found the cause of this bug:
http://davidnaylor.org/blog/2008/09/ie8-and-max-width.html
Perhaps you already know about that one and what is causing it? Would be really greatful for any input.
Pingback ::
Max Design - standards based web design, development and training » Some links for light reading (14/4/09)
[…] Handling an Explicit-Width Bug in Internet Explorer […]
Eric,
sounds a little bit like the known bug IE percentage bugs documented at PIE. Also known to show up with the ALA ‘holy grail’ layout, and a fix for it is discussed http://www.satzansatz.de.
Usually shows up as the ‘jump’ when you hover over something in IE…
What would we do with our time if we couldn’t spend it fixing IE rendering chaos?
Good job on the workaround, I’ve added it to the toolbox.
Ben
Hello Eric,
Interesting IE7- bug. I did a little test and found that if the text within the span also warps to a second line, then the bug disappears.