Unitless line-height bug in Mozilla and Firefox

When Eric Meyer posted Unitless line-heights (you do not need to use a unit when specifying line-height in CSS) earlier this year, I knew that at some point I had run into problems with that. After reading the article I did a bit of testing, but was unable to reproduce the problem. I thought maybe I had just imagined things. After all it was a while since I had last run into any line-height problems.

Like Eric emphasises in the article, unitless line-height is what you want in most cases, so I went through the CSS for 456 Berea Street to fix that. After checking in a whole bunch of the latest browsers I didn’t notice any problems, so I thought all was fine. But it wasn’t.

I didn’t notice the problem until a couple of weeks ago. A couple of readers sent me reports about rendering issues (not related to line-height) in Firefox 1.0.7, so I downloaded that version to have a look. When I viewed this site in Firefox 1.0.7 on my Mac I immediately noticed that the line heights were way too large.

I went back to Firefox 1.5 and the problem was gone. All line heights were the same as in other browsers. I launched Mozilla, and it had the same problem as Firefox 1.0.7. SeaMonkey, however, gets it right.

A Bugzilla search for line-height problems didn’t make me any wiser, but the fact that more recent versions of Gecko behave correctly makes me think that someone noticed the problem and fixed it. It’s hard to tell without seeing a bug report though. What if it was fixed by accident and shows up again in even newer builds?

Determined to know exactly which versions of Gecko-based browsers have the line-height bug I downloaded a set of releases and started testing.

My conclusion is that the bug exists in Firefox versions up to and including 1.0.8 and all versions of Mozilla (but not SeaMonkey), and as far as I can tell it only exists in Mac OS X builds. The bug appears when you assign line-height without specifying a unit and set the font-family to anything but “Times”. Under those circumstances Gecko miscalculates line-height, making it larger than it should be. I made a quick Demo of the unitless line-height bug in Gecko to let you see it in action.

Sure, this isn’t a huge problem, especially considering that it seems to affect only a small minority of users. I still hope I can save someone a bit of grief by posting about it. I have not been able to find a workaround, so if you happen to know of one or have any other information about this bug, please post a comment.

Posted on August 29, 2006 in Browsers, CSS

Comments

  1. Hi Roger,

    No further information, but yeah… I’ve noticed this in the past as well. Only occured to me just now that I haven’t seen it in recent versions of FF - so it does look like it’s fixed. As you point out, there must a bug report somewhere.

    This is one of those things that used to drive me nuts, and I always meant to put aside some time to investigate it properly. Good work!

  2. Just a note to say that it also affects the Mac OS 9 version of the discontinued Mozilla and Netscape browsers. Unfortunatly, these users can’t upgrade to a newer version.

  3. August 29, 2006 by zcorpan

    Looks like #196270.

  4. zcorpan points to the correct bug. That affects all versions of Gecko up to 1.7, on all systems, although the problem is more visible on OS X/OS 9 for some reason (the old-old horrendous Quickdraw based text rendering code ?).

    Not much you can do about it, and face it, it degrades decently.

  5. August 30, 2006 by Roger Johansson (Author comment)

    Good to know that it was fixed intentionally.

    Philippe: Yes, it degrades ok in most cases so I don’t worry about it now. When the affected Gecko versions were more widely used it was a bit frustrating though.

  6. That Eric Meyer is a right trouble maker! ;-)

  7. This bug is correctly fixed in v1.5.0.6 :-) But not in Internet Explorer 7.0 Beta 3 (I didn’t test RC1, maybe it remains). If we didn’t have some line-height attribute, it shows a blank line space. Check it yourself =)

  8. Marco: I just looked at the demo and see no problems in Internet Explorer 7 beta 3, are you using a different test case?

  9. There’s no problems in Flock v.0.7.4.1 (the latest release as of a week ago) either.

  10. I almost started to cry there. I just recently concluded that my website renders a bit wrong in IE 7 and that another version of IE doesn’t mean any less work for a webdesigner just more because a website now needs testing on at least three browsers.

    Thank god that this error is only true for the Mac-versions because then it won’t be necessary to also test a website on Firefox 1.0.x

    By the way - which browsers do a webdesigner need to test on? Right now my websites are going to be tested in IE 6, IE 7 RC1 and Firefox 2.0b1

  11. Roger, just a thought without testing it: would the CSS validator “hack” help? (adding a tenth value to the line-height, e.g. 2.0 instead of 2). I just completed a project with unitless line-heights in this way and have noticed no rendering problems so far.

  12. @Pelle

    which browsers do a webdesigner need to test on?

    Let’s not open up that can of worms here :)

    Eric Meyer’s classic browser support advice

    Yahoo!’s Graded Browser Support policy

  13. @Roger:

    Fancy submitting this find to the QuirksMode Bug Report?

  14. I’m interested to know why anyone would want a unitless line-height? What’s the deal?

  15. Ryan, unitless line-height is the only way to go! ;-) Read Eric Meyers’s article for the long explanation. The short explanation is that when it’s unitless, it scales with the font size. So if you have a nested blockquote that uses a larger font size, the line-height will scale up. If you use units (ems or %) it is computed relative to the current font size and isn’t adjusted later when your nested block has a different size.

  16. Thanks Amit, I had never noticed that could be done without a unit. Good to know!

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.