The IE Word Wrap Doppelganger Bug

Amongst IE6’s usual Guillotine and Peek-a-boo bugs, it’s almost refreshing to see it still has the ability to throw something truly unique and creative at you.

This is a new bug we located on the SitePoint cover page this morning . The XHTML for the feature article isn’t particularly remarkable in any way that I’m aware of:

– DIV#feature is set at a percentage width to scale with the page
– the illustration is placed immediately before the title and floated right
– the H1 title, H5 author credit and P blurb all wrap to the left of the illustration

As images can’t resize themselves, you would fully expect the text to wrap around the illustration as you scaled down your browser window.

And you would be right… to an extent.

As you can see, when a word in the title link runs out of space in IE6, it wraps to the next line, but also leaves a partial copy of itself on the original line — an evil doppelganger.

Bizarre — it’s like the word is torn between taking the plunge, and sticking things out on the line it knows, hoping things will get better.

Continue scaling down the window and the doppelganger eventually topples over the edge and vanishes into the ether again. Of course, scale up a little again and it will reappear on command.

I’ve fixed it on the live site, but here’s a static version if you want to see it for yourself.

I have no explanation as to why this happens — it’s certainly associated with the link — but I have worked out a solution that seems to fix it, should you come across the same problem.

Firstly, the link needs to be switched from it’s default 'display:inline‘ to ‘display:block‘.

 
#feature h1 a {
display:block
}

This will prevent words in the link from wrapping ‘mid-word’, but won’t stop the doppelganger effect — it just duplicates a full word now. To banish the doppelganger, we have to add a padding of at least 1px to our header. Adding a border set to the background color works too, but is more chance of causing other layout problems — for instance, if the user over-rides the background color.

 
#feature h1  {
padding:1px 
}

This certainly works, but forces the extra padding on you — there may be a better solution.

I googled for another occurence of this bug and couldn’t find one, so I’m tipping it’s a bug triggered by very specific set of circumstances.

I still think it’s worth documenting here — the fix is much easier to implement than it is to find in the first place.

On further investigation it appears to be a variety of the ‘haslayout’ bug, meaning adding either ‘zoom:1’ (invalid CSS) or ‘height:1%’ to the header will fix the bug without altering the padding.