Recent Entries

1Big John posted:

13 February 05, 15:28:02 PM

Alas, another fellow more talented than I! Thanks for the great Guest Demo, Jeroen.

2Nathan Piazza posted:

14 February 05, 13:02:26 PM

Jeroen,

Thanks a lot for this. It helped me resolve some line-height issues, and I wanted to share an additional IE line-height bug. This one is definitely in IE 6, but may be in others.

Basically, anytime you assign a line-height value to a containing element (div, ul, etc), and assign the font-size attribute to a contained element (li, span, a, etc), IE calculates the line-height based on the default font-size instead of the specified font-size. This means that no matter how small your font-size and line-height attributes, the line-height will remain a constant 16 pixels or so.

Thus, this code:
<ul style="line-height: 13px;"><li style="font-size: 11px;" /> </ul>

Yields a line-height no smaller than 16px! Yikes!

The fix? Specify your font-size in the containing element, like so:
<ul style="line-height: 13px; font-size: 11px;"><li /></ul>

This must have to do with the way the parser works, etc, but without seeing IE's callback code, it's impossible to know exactly why this occurs.

-Nathan

3Jeroen Mulder posted:

15 February 05, 16:28:40 PM

John - You're very welcome of course. :-)

Nathan - Hmmm. That does indeed sound very strange. I have yet to look into it, but it seems as if MSIE really has major problems correcting the correct leading when it needs to deal with elements that either have no assigned line-height or instrinsic dimensions.

Do you have a stripped live demo of this problem?

4Kevin Steele posted:

04 March 05, 16:19:58 PM

I have been battling this bug for weeks now!

I would describe it to more technical peers, assuming that something so easy to trigger (if you use inline graphics and prefer to specify leading) must have been well documented by now.

Through brute force, and the help of some colleagues I was able to establish, almost conclusively, that it was not something I was doing wrong. Still, I had not found any mention anywhere of what I was sure must be a known bug.

Finally finding your article at Position is Everything was reassuring. At least I am not crazy.

I use inline graphics as controls for showing and hiding embedded notes in this article: When Multimedia Was Black and White and Explorer has been breaking my heart. While the web has driven the perfectionist out of me, I still have high standards.

I'll see if I can make your recommendations work. Thanks for documenting and sharing your efforts.

KS

5Jeroen Mulder posted:

06 March 05, 11:48:50 AM

Kevin - You're welcome. It's good to hear you found it usefull.

Regarding your case, personally, I'd recommend linking the words, instead of the image, instead. Then apply a padding-right to the link and make the image a background-image.

Of course, this will break in MSIE5.x/Win, but a while ago I described (rather bad description, but hopefully understandable) a hack to fix this as well.

6Brian Duchek posted:

06 June 05, 18:21:53 PM

Jeroen, would you say that IE classifies a div with content modified via innerHTML and/or Ajax to be a "replaced element"?

I'm battling an odd bug that has peekaboo like effects - resizing the window in IE reflows the page properly, but in the meantime IE can't seem to figure out how tall some content blocks are. The bug is contained in a floated div, and has other tell-tale signs of peekaboo, but it doesn't want to behave properly with applying the 1% height hollyhack.

Any thoughts are appreciated!

Cheers, brian

7Gary C posted:

29 May 07, 22:52:42 PM

By checking the date of the last reply, I notice that this topic is a bit out-dated, but that does not stop the bug irritates innocent people like me ;-)

Ok straight to the point, lovely fellow on web created this page/site (http://www.brunildo.org/test/IElineheight.html) with a solution. It works for me on IE6.

Enjoy
GC

8Jeroen Mulder posted:

30 May 07, 03:18:55 AM

Gary, thank you for sharing! However, I'd say that's a workaround at best -- similar to the workaround I proposed in the original article. It's not very clean, unfortunately.