Why does Firefox treat Helvetica differently from Chrome?
Asked Answered
D

2

16

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.

demonstration of varying vertical character positions between browsers

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

Deadlock answered 28/1, 2013 at 23:57 Comment(11)
From CSS font differences between browsers: “I see a difference in the width of a given text. I think height is the same.” This question is specifically about content area height and vertical positioning of text within that area.Deadlock
IMO, the answer applies equally well here: "But as hard as you try, you won't get the 100% same look. This is because of the different font rendering strategies browsers and OS use."Lukin
Also, if you don't like that particular question, searching SO yields many more.Lukin
Rendering strategies have more to do with hinting and kerning than defining the size of the content area around the text, which differs here by several pixels. If I’m mistaken about this, I’d love an explanation.Deadlock
FWIW, in windows IE, FF and Chrome all render to something that looks roughly like your chrome example. However, I'd tend to agree that it's not wise to rely on consistency on these matters - at smaller font sizes, the differences can be pretty large.Trickish
Every browser is going to render things slightly different, especially where something has not been standardized by the W3C. Otherwise, not sure what you're looking for here. There is no magic bullet.Lukin
Also, you might want to update your FF version: you're 5 versions behind, and apparently, versions 14+15 introduced some mac-related font changes: support.mozilla.org/en-US/questions/937994 It doesn't sound like your problem, but it's worth a shot.Trickish
As far as I know every webbrowser is pretty much free to render fonts any way they want, as long as it follows the CSS rules. Don't expect all browsers to output the exact same thing, but optimize your code so that it works with any font rendering style.Idalia
If you're interested in the meta discussion on this question, it can be found here.Epenthesis
Adam, I've made some edits here based on the meta discussion and some very helpful feedback from BoltClock. If I'm misrepresenting your interests, feel free to edit further - but try to maintain a cohesive question, please. Re-opened, since I feel what stands is a specific, constructive, answerable question.Hypnos
Thank you, @Shog9. This is very much in the spirit of the conversation from meta.Deadlock
J
4

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

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.


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

Jannjanna answered 1/2, 2013 at 22:57 Comment(2)
I can dig into the sources of the rendering engines used by each browser, but I'll have to save that for later.Jannjanna
Thanks again for doing this research. I looked into the source code. It seems that Webkit has the ability to measure glyphs, but where it puts the baseline in the content area is not based on any standard. This W3C mailing list thread does an excellent job of summarizing the state of typographic baselines in CSS. So far as I can tell, nothing has changed the last couple of years: lists.w3.org/Archives/Public/www-style/2012Jan/0381.htmlDeadlock
B
-1
  • 'Line height is auto' => the browser gets to choose.
  • 'Line height = font size' => user error: the text will be illegible, and again it is reasonable, indeed essential, for the browser to make some adjustment.

You must use some leading. Books for example may be set 10pt on 12pt line spacing.

Benco answered 1/2, 2013 at 23:27 Comment(1)
This question is not about the legibility of different line-height values. It’s about differences in behavior between browsers and the standards that govern them. Besides, I think you may be confused about how line-height works: it “specifies the height that is used in the calculation of the line box height”. Setting it to the same value as font-size is admittedly condensed, but not illegible.Deadlock

© 2022 - 2024 — McMap. All rights reserved.