When I first wrote Cascading Style Sheets: The Definitive Guide, the part that caused me the most difficulty and headaches was the line layout material. Several times I was sure I had it all figured out and accurately described, only to find out I was wrong. For two weeks I corresponded with Ian Hickson and David Baron, arguing for my understanding of things and having them show me, in merciless detail, how I was wrong. I doubt that I will ever stop owing them for their dedication to getting me through the wilderness of my own misunderstandings.
Later on, I produced a terse description of line layout which went through a protracted vetting process with the CSS Working Group and the members of www-style. At the time it was published, there was no more detailed and accurate description of line layout available. Even at that, corrections trickled in over the years, which made me think of it as my own tiny little The Art of Computer Programming. Only without the small monetary reward for finding errors.
The point here is that line layout is very difficult to truly understand—even given everything I just said, I’m still not convinced that I do—and that there are often surprises lurking for anyone who goes looking into the far corners of how it happens. As I’ve said before, my knowledge of what goes into the layout of lines of text imparts a sense of astonishment that any page can be successfully displayed in less than the projected age of the universe.
Why bring all this up? Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose. As with all driven to such madness, I now seek, grinning wildly, to infect others.
Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also vary within a given face.
I did not expect that. At least, not consciously.
My work, let me show it to you: a JavaScript-driven test file where you can pick from a list of fonts and see what happens at a variety of sizes. (Yes, the JS is completely obtrusive; and yes, the JS is the square of amateur hour. Let’s move on, please. I’m perfectly happy to replace what’s there with unobtrusive and sharper JS, as long as the basic point of the page, which is testing line-height: normal, is not compromised. Again, moving on.)
When you first go to the test, you should (I hope) see a bunch of rulered boxes containing text using the very common font face Webdings, set at a bunch of different font sizes. The table shows you how tall the simple line boxes are at each size, and therefore the numeric equivalent for line-height: normal at those sizes. So if a line box is using font-size: 50px and the line box is 55 pixels tall, the numeric equivalent for line-height: normal is 1.1 (55 divided by 50).
On my PowerBook, Webdings always yields a 1:1 ratio between the font-size and line box height. The ten-pixel font size yields a ten-pixel-tall line box, and so on.
This is actually a little surprising by itself. The CSS 2.1 specification says:
- normal
- Tells user agents to set the used value to a “reasonable” value based on the font of the element. The value has the same meaning as <number>. We recommend a used value for ‘normal’ between 1.0 to 1.2. The computed value is ‘normal’.
This is basically what CSS has said since its first days (see the equivalent text in CSS1 or in CSS2 for confirmation) and there’s always been a widespread assumption that, since 1.0 is probably too crowded, something around 1.2 is much more likely.
So finding a value of 1 was a surprise. It was an even bigger surprise to me that this held true in Camino 1.5.2, Firefox 2.0.0.14, and Safari 2.0.4, all on OS X. Firefox 3b5 didn’t render Webdings at all, so I don’t know if it would do the same. I actually suspect not, for reasons best left for another time (and, possibly, a final release of Firefox 3).
Various browsers doing the same thing in an under-specified area of the spec? That can’t be right. It’s pretty much an article of faith that given the chance to do anything differently, browsers will. The sailing was so unexpectedly smooth that I immediately assumed was that a storm lurked just over the horizon.
Well, I was right. All I had to do was start picking other font faces.
To start, I picked the next font on the list, Times New Roman, and the equivalent values for normal immediately changed. In other words, the numeric equivalents for Times New Roman are different than those for Webdings. The browsers weren’t maintaining a specific value for normal, but were altering it on a per-face basis.
Now, this is legal, given the way normal is under-specified. There’s room to allow for this behavior. It’s actually, once you think about it, a fairly good thing from a visual point of view: the best default line height for Times New Roman is probably not the best default line height for Courier New. So while I was initially surprised, I got over it quickly. The seemingly obvious conclusion was that browsers were actually respecting the fonts’ built-in metrics. This was reinforced when I found that the results were exactly the same from browser to browser.
Then I looked more closely at the numbers, and confusion set back in. For Times New Roman, I was getting values of 1.1, 1.12, 1.16, 1.15, 1.149, and 1.1499. If you were to round all of those numbers to two decimal points, you’d get 1.10, 1.12, 1.16, 1.15, 1.15, 1.15. If you round them all to one decimal place, you’d get 1.1, 1.1, 1.2, 1.2, 1.1, 1.1. They’re inconsistent.
But wait, I thought, I’m trying to compare numbers I derived by dividing pixels by pixels. Let’s turn it around. If I multiply the most precise measurement I’ve gotten by the various font sizes, I get… carry the two… 11.499, 28.7475, 57.495, 114.99, 1149.9, 11499. As compared to the actual values I got, which were 11, 28, 58, 115, 1149, and 11499.
Which means the results were inappropriately rounded up in some cases and down in others. 28.7475 became 28 and 1149.9 became 1149, whereas 57.495 became 58. Even though 11.499 became 11 and 114.99 became 115.
This was consistent across all the browsers I was testing. So again, I was suspecting the fonts themselves.
And then I switched from Times New Roman to just plain old Times, and the storm was full upon me. I’ll give you the results in a table.
Derived normal equivalents for Times in OS X browsers
font-size |
Camino 1.5.2 |
Firefox 2.0.0.14 |
Safari 2.0.4 |
| 10
| 1 |
1.2 |
1.3 |
| 25
| 1 |
1 |
1.16 |
| 50
| 1 |
1 |
1.18 |
| 100
| 1 |
1 |
1.15 |
| 1000
| 1 |
1 |
1.15 |
| 10000
| 1 |
1 |
1.15 |
Much the same happened when comparing Courier New with plain old Courier: full consistency on Courier New between browsers, albeit with the same strange (non-)rounding effects as seen with Times New Roman; but inconsistency between browsers on plain Courier—with Camino yielding a flat 1 down the line, Firefox going from 1.2 to 1, and Safari having a range of values above the others’ values.
Squamous! Not to mention rugose!
Now it’s time for the stunning conclusion that derives from all this information, which is: not here. Sorry. So far all I have are observations. I may turn all this into a summary page which shows the results for all the font faces across multiple browsers and platforms, but first I’ll need to get those numbers.
I do have a few speculations, though:
-
Firefox’s inconsistency within font faces (see Times and Courier, above) may come from face substitution. That’s when a browser doesn’t have a given character in a given face, so it looks for a substitute in another face. If Firefox thinks it doesn’t have 10-pixel Times, it might substitute 10-pixel something else serif-ish, and that face has different line height characteristics than Times. I don’t know what that other face might be, since it’s not Times New Roman or Georgia, but this is one possibility. It is not the minimum font size setting in the preferences, as I’ve triple-checked to make sure I have that set to “None”.
-
Another possibility for Firefox’s line height weirdness is a shift from subpixel font rendering to pixelly font rendering. 10-pixel text in Firefox is distinctly pixelly compared to the other browsers I tested, while sizes above there are nice and smooth. Why this would drive up the line height by two pixels (20%), though, is not clear to me.
-
Much of what I’ve observed will likely be laid to rest at the doorsteps of the font faces themselves. I’d like to know how it is that the rounding behaviors are so (mathematically) messed up within faces, though. Perhaps ideal line heights are described as an equation rather than a simple ratio?
Again, this was all done in OS X; I’ll be very interested to find out what happens on Windows, Linux, and other operating systems. Side note for the Mac Opera fans warming up their flamethrowers: I’ve left Opera 9.27 for OS X out of this because it seems to cap font sizes at a size well below 1000, although this limit varied from one face to another. Webdings and Courier capped at 507 pixels, whereas Courier capped at 574 pixels and Comic Sans MS stopped at 707 pixels. I have no explanation, though doubtless someone will, but the upshot is that direct comparisons between Opera and the other browsers are impossible. For sizes up to 100 pixels, the results were exactly consistent with Camino, if that means anything.
The one tentative conclusion I did reach is this: line-height: normal is a jumbled terrain of inconsistent behaviors, and it’s best avoided in any sort of precision layout work. I’d already had that feeling, but at least now there’s some evidence to back up the feeling.
In any case, I doubt this is the last I’ll have to say on this particular topic.
Update 7 May 08: I’ve updated the test page with a fix from Ben Lowery so that it works in IE. Thanks, Ben! Now all I need is to add a way to type in any arbitrary font-family’s name, and we’ll have something everyone can use. (Or else a way to use JavaScript to suck up the names of all the fonts installed on a machine and put them into the dropdown. That would be cool, too.)
Ged knows I would love to be in a Unicode world, or indeed any world where such character-incompatibility idiocy was a thing of the past. The fact that we still have those problems in 2008 almost smacks of willful malignance on the part of somebody.