line-height: abnormal

Published 16 years, 7 months past

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:

  1. 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”.

  2. 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.

  3. 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.)

Comments (61)

  1. Hey there! I’d very much like to test on Linux, but I have pretty much none of the fonts on that list. I can install those fonts or add applicable ones using Firebug, but I suspect this is the case for most Linux users.

    Is there any chance you can add “Nimbus Sans L”, “Bitstream Vera Sans”, “Century Schoolbook L”, and “Liberation Sans”? I think that runs the gamut of some typical Linux fonts.

  2. Could this be related to the hinting in the fonts? I didn’t think hints could affect line height, but maybe they can.

  3. Interesting. On FF 2.0.0.14 / Windows XP, Times yields 1.2, 1.2, 1.8, 1.8, 1.49, 1.499.

    I take that back. I’m not sure what those numbers are for. I just realized that the samples don’t show Webdings in FF, and the font isn’t changing. In IE 7, Webdings show, but again the font doesn’t change.

    Javascript problems?

    (The numbers in IE 7, for reference, are 1.6, 1.12, 1.02, 1.01, 1, 1)

  4. I’m quite willing to believe you’re right — line-height really should be computed based on font metrics, and it’s very likely to be more complex than a simple constant for each typeface. This is because, unless I’m mistaken, glyphs may actually change shape when rendered at different sizes. Additionally, bitmapped fonts (such as Times and Courier) may behave subtly but fundamentally differently from TrueType fonts.

    It might be worth seeing if the folks at I Love Typography could shed more light on the situation here.

  5. Sorry to be that guy, but there’s a typo: “sqamous”

    [Fixed. Thanks! -E.]

  6. If anyone finds JS problems on Windows (or anywhere else) and comes up with a fixed version, I’d be more than happy to replace my JS with the improved stuff. I’ll also try to get some Linux fonts on the list, but right now I’m already five minutes late so it’ll have to wait until later. (But feel free to save a local copy, edit the source, and try it out.)

  7. “The font size corresponds to the em square, a concept used in typography. Note that certain glyphs may bleed outside their em squares”

    – So the 10px font is actually never 10px in full height!

    – I tested with Gerorgia & Times on Safari OSX and changed the phrase to OyÄ! – actual height IS 12px by Georgia and 11px by Times. I assume in Georgia something is rendered even higher than Ä, was to lazy to figure out which glyph.

    – I assume it is difficult to render fonts in small pixel sizes, so 10px Georgias actual size from the lowest bottom pixel to the highest upper pixel 13px seems reasonable. It gets easier with big sizes – so the line-height drops.

    – Firefox LIES, change the box’s background-color and you’ll see. It informs that the box is 10px high, it is, but it paints the font outside of the box! So visually correct height on FF is 13px on 10px Georgia.

  8. I think the answer is definitely in the font metrics themselves. Astonishingly, there isn’t one single way to make vertical font metrics work across the board consistently. Different programs look at different specs, even on the same platform.

    I would also assume that the reasons that Times and Times New Roman and Courier and Courier New match is because they were designed to have matching metrics for cross-platform use in standard documents.

    For a full technical discussion, see Setting Cross-Platform Vertical Metrics at Typophile.com’s Typowiki.

  9. Pingback ::

    line-height: normal Considered Harmful | Play Work Play Studio

    […] Here’s Eric Meyer’s discovery on the issue. The intrinsic value of “normal” for different font faces on different browsers, it turns out, is totally wacky. The moral of the story is to simply avoid using it for any precision, cross-browsers compatible work. Which is all the time, I should say. Dragonfly, New Web Development Tools from Opera […]

  10. Firefox 3.0b5 adds another wrinkle: all of the fonts have bogus low values for the 10,000 pixel test, usually in the 2100-2500 range (0.21 to 0.25 “normal” values). I suspect a limit is being hit in the Cairo graphics layer that Gecko 1.9 has switched to. Don’t have FF3 installed in Windows yet, so I’m not sure if that’s a cross-platform issue, or an issue with the OS X implementation.

  11. For some strange reason my brain switched Times and Georgia in my response. Times 10px line-height is 13px. Sorry.

  12. Isn’t this the sort of time to email someone at the various browser makers and say, “Dude! What gives?”

    Or better still, break out the source code from Mozilla?

    We’re all clear in that the spec is vague … so let’s just ask the guys who implemented the spec.

  13. Firefox 2.0.0.14 on Windows XP.

    Arial: 1.3, 1.16, 1.18, 1.15, 1.15, 1.1499
    Comic Sans: 1.4, 1.36, 1.42, 1.4, 1.394, 1.3936
    (which are at least all about 1.4)
    Courier: 1.6, 0.96, 1.16, 1.2, 1.149, 1.1499
    Courier New: 1.2, 1.16, 1.06, 1.07, 1.133, 1.328
    Verdana: 1.2, 1.24, 1.2, 1.21, 1.215, 1.2154

    I think Courier is as bad as it is because it isn’t a True Type font on my system – although it looks like another font has been substituted for 1000px and 10000px.

  14. Pingback ::

    Ess - Sibran Lens » The abnormal line-height story by Eric Meyer

    […] Read the entire article of Eric Meyer […]

  15. Squamous! Not to mention rugose!

    Your word skills are way beyond my puny mind. (Or, I have no idea what those words mean!)

    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 varying within a given face.

    I think the last part isn’t quite correct? Should it be “and can also vary”?

    [Indeed. Fixed. Thanks! -E.]

  16. I noticed Firefox’s weird line-height behaviour a few years ago since it’s visible on a huge number of sites, including your own.

    Look at your largish paragraph near the end of the article (there are other examples too) and highlight it (Firefox on Windows for me) There is a very clear pixel difference between some lines compared to others (which line it is depends on screen width), at first it looks like it might just be how the highlight renders but take a screenshot into photoshop and it’s clear that there’s a difference.

  17. Pingback ::

    Mac Fan Boy » Thoughts about Line-Height.

    […] dude did some investigations into the line-height css […]

  18. I notice Opera 9.5 Alpha on OS X doesn’t update the fonts, until you scroll down and up to refresh the screen. Although I’m not using the latest in-house builds, so this may have been fixed.

    Odd how Firefox 3 Beta 5 doesn’t show Webdings.

    Anyone tried the test in IE8 Beta 1? I would do, but I’ve had to uninstall it ready for XP Service Pack 3, as Microsoft say to do. I can reinstall it after that.

    Oh, and it’s a very nicely made demo Eric. Love the Webdings characters you used.

  19. You crashed my Firefox :-(

  20. The “weird” line-height behaviour of firefox is caused by fractions of pixels actually being calculated into the resulting height of a box. You can see it in action here; http://www.xs4all.nl/~peterned/lines.html

    There’s a bit of js in the source which I used to check the computed values. The difference in offsetheight of the two floating paragraphs is 2px, which can only be caused by the percentage based line-height fractions. Where these fractions come from is a mystery to me, since 1.2em and 120% should evaluate to the same value.

    The rendering engine places each line on a nice pixel, regardless of fractions. Rounding causes the odd pixel every now and then.

  21. Greetings,

    I took a look at the code and ported it over to use the CDN-hosted Dojo, and made it work with IE (at least 7). My version is available at http://blowery.org/js/inspect-multi.html.

    If you want to fix your version to work with IE, just change the value grabber to the following:

    name = menu.options[menu.selectedIndex].text;

  22. Thanks, Ben! I’ve updated my version and will update the post with credit. You rock.

  23. Yes, this entry is already on page one of a Google search for “squamous and rugose.”

  24. Sebastian: That’s unfortunate! The file doesn’t crash Firefox (either 2.0.014 or 3.0b5) on my machine, so I’ve no idea why that might be happening. If someone can work out what causes it and come up with a way to avoid it, I’ll certainly want to act on that.

  25. Chris: thanks for the information (and kind words). I’m mystified by the lack of Webdings in FF3b5 myself, but am currently taking a shrugging “it’s a beta” approach. I haven’t tried out IE8b yet, as I fairly dread launching VirtualPC (no, I don’t have an Intel Mac yet). I’ll get there eventually.

  26. Eric, I have explained this to you before, but maybe you don’t recall the conversation…

    Safari actually alters the metrics of Times on Mac only to more closely match Times New Roman. This was done for Windows compatibility back when Times New Roman wasn’t typically present on Macs.

    Now that Times New Roman ships by default on OS X, we may end up removing this hack eventually, but it was useful a few years ago for Web site compatibility.

  27. The same is true for Courier New vs. Courier (i.e., we hacked the metrics).

  28. I remember fragments of our font-metric conversation, but not everything—it was part of the line-height stuff I raised on www-style, yes? Anyway, I’m not saying that what Safari does is wrong, nor did I mean to imply such if I did so. In fact, the bit that weirds me out the most is Firefox’s 1.2-to-1 shift.

    But you only do this for ‘normal’, so far as I can tell. For explicit numeric and length values, it looks to me like you ignore the font metrics and do what the CSS says. Right?

  29. Pingback ::

    GarotaDPI » Blog Archive » Leitura de hoje:

    […] Eric Meyer: line-height: abnormal […]

  30. I was just complaining about line-height to my friend here when he pointed me this way.

    My complaint was not so much with the normal attribute as the behavior of set line-heights.

    For example, in Photoshop, if you put multiple font sizes in the same leading – say, 10px and 28px – the baseline stays in the same place, and the space above the type becomes larger, which can create a nice rhythm (in my opinion.)

    In Safari and Firefox at least, it seems to me that the type becomes centered in the line-space, so that the baseline position changes between the two type sizes. If you want the afore-mentioned nice rhythm effect, you have to fudge it.

    Maybe that’s the intended behavior, I dunno.

  31. Awesome post!

    This discussion reminds me of one layout I did long ago that I have a menu with tabs in Trebuchet MS.
    Everything was fine until I got a Mac to test thing up. The line height from all browsers on windows wore shown consistently. All browsers the same on the Mac. But I was amazed to see that all the browsers on mac had a line-height something about 10-20% bigger then all the browsers in Windows.
    The layout was broken because of it and I solved the problem with a mess of font-familys and overflow:hidden. And line-height as not set at normal!

    Now I’m on Firefox 2.0.0.14 on Windows XP shows for Trebuchet:
    10px 15 1.5
    25px 32 1.28
    50px 63 1.26
    100px 125 1.25
    1000px 1161 1.161
    10000px 11612 1.1612

    Any differences on the Mac? I never taken the time to write a test about it before, may be thats the time.

  32. Jesse, Eric has used the core web fonts which you can download via sourceforge of you don’t have them (I recommend you do; they’re the the only common typefaces we have and as such the backbone of web typography).

    Eric, thanks for this. I’ve been wanting to preform the same test for a while. Safari 3.1.1 on OSX 10.5.2 has less painful rendering with ATSUI / Core Text in Leopard but still exihibits the same inconsistency.

    I’ve long thought that a leading property would be welcome alternative to line-height to give designers the precision we crave. However, that would require the baseline position to be more consistently rendered. Your excellent suggestion for a computed line-height based on a ratio would provide such consistency. However, I have a feeling that there are issues around grid-fitting and versus sub-pixel rendering across platforms that would preclude this from happening and somehow account for the inconsistencies.

    On a related note, this may be similar to my observation that when drawing a line set in em lengths, Safari rounds down any values that do not correspond to a fixed pixel size, whereas Firefox rounds up.

  33. 1. You surprise me. The line-height:normal is based on the metrics returned by the specified font. Thus it is correct that two different fonts return different values. On average it is around to the equivalent of 1.2 in numerical values. You don’t want Zapfino to have the same (intrinsic) line-height as say Times or Ahem, do you ?

    2. WebDings. I’ll argue that what Gecko 1.9 (Fx 3) does is correct. You ask to display the characters Oy!. Gecko 1.9 does that. See Gecko bug 399636 and all those other bug reports linked from there. Don’t expect any change in Gecko 1.9 final.

    3. at very small sizes (10px) the returned values may be incorrect, due to rounding. Surprised by the values for 10000px in Gecko 1.9. As commented above, it could be a limit in Cairo, or it could be a bug.

    4. Gecko 1.8 Mac is known to do some not-so-pretty things with font-size (and line-height) due to the old-old underlying text technology used (QuickDraw).

  34. Philippe:

    1. Sometimes I surprise even myself. In this case, though, the wording in CSS doesn’t lead to an immediate assumption that ‘normal’ line-heights will be determined by the font. Yes, the wording allows for that, but it implies that ‘normal’ will equate to some number. The obvious (if wrong) assumption is that it will be some constant number, the same as if I’d declared a numeric line-height for, say, the body element. Now, I’m not objecting to what browsers do—I think it’s better than assigning a universal number—but it’s not what I had expected from reading the specification.

    2. Thanks for the bug 399636 reference. I’ll argue that what Gecko does is deeply unexpected, and very possibly incorrect. If I go into any text editor, set the font to “Webdings”, and type “Oy!”, I’ll get three symbols—the glyphs defined in that font for the characters I input. In Gecko 1.9, I get substitutes from an entirely different and unrelated font face. That makes very, very little sense to me (and, I’d wager, to almost anyone).

    3. I don’t think the Firefox difference at 10px is entirely due to rounding. If I set ‘line-height: 1’ then the line box is 10 pixels tall, not 12. Something else is happening with ‘normal’.

  35. Fantastic work, Eric. What a confusing situation indeed.

    You mentioned wanting to be able to list fonts on the user’s machine. I think you’ll find this helpful for doing just that. (As seen on Typetester)

    Cheers.

  36. Eric, if you are confused about this imagine the rest of us, I’m just amazed that the interwebs works after all :).

  37. In IE7, webdings starts at a whopping 1.6 for 10px, drops dramatically to 1.12 for 25px, and approaches 1 for bigger font sizes (50 and 100 have line-heights of 51 and 101, 1000 and 10000 have heights of 1000 and 10000).

    Courier is even weirder:

    10px: 1.3
    25px: 0.8 (well below zero, that can’t be right??)
    50px: 0.96
    100px: 1
    1000px: 1.133
    10000px: 1.1328

  38. This is all further evidence why it is perhaps foolish to try and create another rendering engine/browser from scratch. (Hello Microsoft!) There are just a zillion factors to allow for. (Vertical text anyone?) And every browser maker seems to do things slightly differently. (Plus the specs, which are only recommendations anyway, are often confusing.) Why can’t we have just one renderer and be done with it – so long as it is fully standards-based, future proof and without major layout bugs. My vote is for Gecko at this moment in time. It’s not perfect, but pretty darn good. Now imagine designing web pages if that was the ONLY system you had to design for. Heaven! Any bugs would be easily worked around in a standard way, and you wouldn’t have to tear your hear out testing in so many different browsers and platforms. (Sometimes I find it is impossible to create cross-browser code. Sometimes you just have to abandon parts of a brilliant new layout you created and opt for something less interesting just to ensure it works for everyone.) At least with just one renderer you’d know where the goalposts were.

  39. I might sound naïve, most of my experience being in print and not online, but how else would you deal with the various x-heights of different fonts, and the different ways different OSes and browsers render them? Calling a line height “normal” and expecting a constant value seems overly simple considering in print one has to manually set the leading in the style sheet all the time.

  40. display:inline controls line-height [indirectly]
    component for next CSS Reset?
    compare with Django Boilerplate: critically their operations accessibility suffers top-heavy VSN bias – nothing for CSS developers who crave creativity! Their take on line-height involves server resets for ‘inline’. However, Django’s boilerplate has me looking for ways to deploy XHTML line-height control using reset.css (Google Code). Is it ‘reset’ if i open an atypical line-height and close it in the same style block? or #wrapper{display:inline-block;} p #wrapper{line-height:0;} – simple reset div p{display:inline-block breaks “some” IE, O and FF teasing and background menubar image flunks (1st instance perfect, 2nd insatnce 50% vertical flunk)

    display reset semantics?
    Opera bloats line-height next to high specificity borders – IE, O and FF both tease/flunk liquid floats into line-height distortion
    UNLESS the display selector is flattened in the right place(s)… so,
    we tossed inline-block into a reset run and it helped
    certain here that display selector is key to line-height control

    reset involves complex grouping of inter-related selectors
    need help
    display:inline-block line-height CSS Reset v2, Eric?

  41. Re “font margins” (your concern in this discussion is thus pointed, and they are so-named by typographers) of course they display differently everywhere (by creative design) …unless you flatten margin potentials! …so, [display:]inline reset!

  42. Eric,

    1. The spec says, for the ‘normal‘ keyword:

    Tells user agents to set the used value to a “reasonable” value based on the font of the element

    From CSS 2.1:10.8.1, my emphasis.

    And, sidenote, when you think about it, for a generic stylesheet such as an UA stylesheet, using a value based on the font-metrics is a good approach, given that nobody knows what the user will set as default font. I had started writing a longer comment on this, but I’ll reserve that for an article on its own, some day, somewhere.

    2. If you consider the Gecko 1.9 behaviour with Webdings incorrect, please file that in Bugzilla. You know your way there. It will likely get more attraction (and a resolution).

    3. Assuming the font you’re using has a intrinsic line-height that computes to 1.1678. The height of the line-box would then be 11.678px. Rounded of this can go to 12px or 11px depending on the UA. WebKit rounds off downwards much more heavily than Gecko 1.9. Next, have a bit of fun with Bruno Fassino’s plotting graphs.

  43. Pingback ::

    Max Design - standards based web design, development and training » Some links for light reading (13/5/08)

    […] line-height: abnormal […]

  44. 2. Thanks for the bug 399636 reference. I”ll argue that what Gecko does is deeply unexpected, and very possibly incorrect. If I go into any text editor, set the font to “Webdings”, and type “Oy!”, I”ll get three symbols—the glyphs defined in that font for the characters I input. In Gecko 1.9, I get substitutes from an entirely different and unrelated font face. That makes very, very little sense to me (and, I”d wager, to almost anyone).

    What Gecko 1.9 does is absolutely correct and expected in a Unicode world. If this were 1990, I”d (possibly) agree with your statement, but not in a Unicode world. When you typed “Oy!”, you requested the glyphs for “O” “y” and “!”, not those for “ear”, “circle with a horizontal line through the center”, and “spider”[1]. If Webdings does not contain the glyphs “O” “y” and “!”, then the application should select another font that does contain those glyphs in order to display “Oy!” properly. Gecko 1.9 does this.

    Changing a font face should never change the glyph displayed. Unicode requires every glyph to have a unique “id”, and the only way to display that glyph is to use its id; interoperability (and machine comprehensibility) depends on it. Or, put another way, think of the glyphs like HTML structure and the font face as CSS presentation; if I have a <p> element somewhere and I change the font-size for that <p> in CSS, that doesn”t suddenly turn the <p> into an <h1> element.

    By the way, I don”t know what text editor you”re using, but in any Unicode-based application, changing the font to Webdings and typing “Oy!” produces the glyphs “Oy!” (try in TextEdit on Mac OS X, for instance).

    [1] As long as you didn”t first switch to a dingbats keyboard layout; if you used a Unicode dingbats layout to request the Unicode glyphs for “ear”, “circle with a horizontal line through the center”, and “spider” (or whatever they may be called), you should see those glyphs provided you have a font that contains them.

  45. Pingback ::

    Links of Interest - CSS-Tricks

    […] Meyer digs into some of the peculiarities of line-height: Here”s the punchline: the effects of declaring […]

  46. Pingback ::

    Great Resources Elsewhere: May 08 to May 15 - CSSnewbie

    […] Eric’s Archived Thoughts: line-height: abnormal […]

  47. Pingback ::

    CSS Collection » Blog Archive » line-height: abnormal

    […] the great CSS master, Eric Meyer, gets frustrated with line layout. He thinks out loud about line-height: normal, which is more like abnormal. Take a look. Friday, May 16th | […]

  48. And for the others, if any, that have no idea what ‘rugose’ means…..

    http://www.thefreedictionary.com/rugose

    Stay on groovin’ (Say what?) safari,
    Tor

  49. Anybody notice anything strange with line-spacing and Cambria Math?

  50. Re: “Update 7 May 08: I”ve updated the test page with a fix from Ben Lowery so that it works in IE…”

    It doesn’t work in 6.0.2900…..

  51. I have been looking at the font-height issue also because I want to extract font-metrics in JavaScript. I have found that line-height:normal gives just enough vertical space to display all of the characters. If you display a box drawing character plus an open bracket or brace typically there is one pixel above and below the black space. Obviously that may vary a bit, but if you want the metrics then line-height:normal gives the minimum height you need to display a line of text without overlap.

  52. I have found that if I select a font with “font-size: #px” that the font that I get back has ascender + descender = #, which is also the height that I get from using line-height:100%. If I then use line-height:normal I get ## = ascender + descender + internalLeading + externalLeading where the externalLeading component is added by some browsers and not by others. It is zero for most fonts. Typically I have found a pixel or two variation in line-height:normal result, but it is very close between several browsers and across several dozen fonts and handfull of font sizes. I found only one case where line-height:normal < line-height:100% and that was where the font had a garbage value for the internalLeading value. There are some fonts with internalLeading = 0 and in that case line-height:100% = line-height:normal unless the externalLeading is non-zero, which doesn’t affect all browsers. The minor variations I get are probably due to round-off, fudge factors and slight differences in font matching results. However, this seems to be extremely consistent.

  53. Pingback ::

    Eric’s Archived Thoughts: line-height: abnormal | CSS Tutorials - CSSHelper.net

    […] Source […]

  54. Hinting may be effecting the line height. There are vertical hints in fonts. If it is, then the line height may also change depending on which what letters you use and if anti-aliasing is turned off or on.

  55. i’m confused. united line-height can cause text overlap, while unitless/multiplier can break vertical rhythm. if unitless line-height is being advocated, how do you recommend avoiding breaking vertical rhythm?

  56. Hi, Eric,

    As usual, I stmbled across your site today while surfing for a CSS solution. My problem was with Firefox/Win. I’m on Ubuntu, and oddly enough, the issue doesn’t exist there.

    I’m developing an Armenian/English translator and I noticed that FF/Win was chopping off the bottoms of some of the Armenian glyphs in text input boxes. I assumed a line-height:1.5 rule would help, but quickly noticed that Firefox was ignoring any line-height settings on input elements.

    A quick check in Firebug revealed that the FF/Win style sheet is declaring input{line-height:normal!important;}.

    Re-declaring !important and over-specifying the selector, I changed the style sheet on the site to this:
    :root input[type=text]{line-height:1.5!important;}
    …which fixed the problem.

    I’m posting it here since this page came up during my Google search and anybody searching in the future might benefit from this tidbit. Hope you don’t mind. :)
    –Bill

  57. Please ignore my previous post.

    The solution I posted does NOT solve the problem. An !important rule in the User Agent style sheet cannot be over-ridden by an author style sheet.

    As of 2010-FEB-08 (and as far as I know), there remains no solution.

    Bill

  58. Pingback ::

    The Firefox Input Button Line-Height Bug

    […] their part, particularly considering (as Eric Meyer has pointed out at great and detailed length), line-height: normal is anything but.And while trying to work around this rule, I discovered something that makes the situation a little […]

  59. Eric, do you consider these findings as well as your work with http://meyerweb.com/eric/css/inline-format.html to still hold? (I’m a bit lazy here as it might only take a second to confirm.)

  60. Pingback ::

    Fun with Web Fonts | Gliffy Blog

    […] Talk about ambiguous! Thankfully, Eric Meyer, wrote a pretty great article on the subject in 2008 and created a fantastic tool for analyzing line heights across […]

  61. Alright, regarding line-height:normal

    So I think I have figured it out. But first let me explain some things about truetype fonts. They have something called an “EM size”. They also have (several) sets of Ascender and Descender metrics, read with different priorities on different operating systems. The ascender and descender are supposed to add up to the EM size, but for some of these sets of metrics it does not.

    I have determined that normal uses the OS/2-uswinas-/decender values without scaling them to em size as raw values for the line-height. (But then still renders the characters at the em-size)

    I’ve written a rudimentary html parser, TTF font parser (and writer) as well as a PDF creator mostly from the ground-up, and can confirm this behavior.

    line-height:1 is also quite easy to explain,

    but line-height:10px still eludes me…

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview