Why does Firefox treat Helvetica differently from Chrome?

Question

The vertical position of text rendered in Helvetica and the size of its content area differ between Firefox and Chrome for Mac. For example, in Chrome, the descenders are clipped if the line-height is identical to font-size.

(I’ve adjusted the position of the block elements in this picture—keeping the baseline consistent—to illustrate the difference in size and text positioning). If you have a Mac, you can see what I’m talking about in this JS Bin.

Now, I'm not directly interested in how to fix this specific discrepancy. I realize there are hand-tuned reset stylesheets that attempt to eliminate or paper-over the differences, but I'm specifically interested in the factors that caused these browsers to render differently in the first place.

I'm making some assumptions here:

• Standards exist for both the rendering of fonts and the sizing and positioning of glyphs within the standard box model, but may be unspecified in terms of how they interact.

• Bugs exist in browser-makers interpretations of the aforementioned standards, which may influence how text is sized, positioned and rendered.

• For these specific browsers, much of the design discussion and actual implementation is public in some form. Therefore, it is possible to learn the source of such discrepancies, if one knows where to look.

• Both browsers start in the same place - the markup, styles and font definitions are consistent between them. At some point, they diverge in how they use these to produce the final output.

Therefore, my specific question is: where in the process does this divergence occur, and what causes it to occur?

I feel that, armed with this knowledge, I can better understand how to correct for such discrepancies. Both in this case specifically, and in similar situations that I may encounter in the future.

Answer 1

Unfortunately, re: rendering of the content area based on the font, CSS2.1 does not say much at all:

The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. (The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the 'line-height', but leads to glyphs painting outside their content area.)

In other words, typesetting, and how exactly to draw and position the content area of a line box, is left up to the browser's own implementation, at least in CSS2.1. This may however be better defined in a future specification (likely the Fonts module, if not a separate module¹).

Section 10.8.1 contains some details on how the line-height property affects the rendering of the content area around text that flows inline, but again it depends on the height of the content area itself, which as stated above is undefined in CSS2.1.

Note that auto is not a valid value for line-height; you probably meant to use normal, which incidentally is also its initial value (but not necessarily the browser default). Also, this is what the spec says about the value normal:

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 . We recommend a used value for 'normal' between 1.0 to 1.2. The computed value is 'normal'.

As you can see, there's not much to go on, even with regards to comparing line-height: normal and line-height: 1 (or 1em or 100%), because what constitutes a "normal" line height is up to the browser to decide as well. However, it looks like Chrome and Firefox do a good job of keeping glyphs within reasonable boundaries when asked to use a normal line height.

By the way, Chrome does not clip the descenders. It does render them outside of the content box, but it should never clip them to the bounds of the box unless you set overflow: hidden.

---

¹_{A CSS3 definition of the line-height property currently resides in this module, but it's immediately obvious that it's been long abandoned, or at least pending a rewrite. The module in its current state is extremely detailed, but suffice it to say that it's been largely ignored by both browser vendors and the working group.}