Why Does Firefox Treat Helvetica Differently from Chrome

Why does Firefox treat Helvetica differently from Chrome?

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

Text vertical alignment within button on Firefox and Chrome when using Helvetica

This doesn't have anything to do with the <button> element, it's a generic issue related to the difference between how Firefox and Chromium treat font metrics embedded in font files.

You've already identified the easiest solution, which is to use Arial instead of Helvetica. Or, if you specify an actual typeface (using @font-face), then that would give you control over the actual typeface used by the browser (not just the font name) and then you could specify a web font that you know to render consistently across browsers.

Alternately (and this would be a hack, but it's up to you) you could use a CSS rule to target Firefox and use different padding depending on the browser, and then you could still use font-family: Helvetica. But, test thoroughly. Because there are so many licensed/unlicensed/mock versions of Helvetica and Helvetica Neue kicking around, simply specifying font-family: Helvetica leaves it up to whatever Helvetica font each person's Mac/Linux/Windows/Android/iOS device has installed, which is likely to be a crapshoot.

I'm not the arbiter for which browser is "correct" but based on this discussion it appears that it's Firefox, they've implemented full font metrics whereas Chromium ignores them. Here's a related question.

Again, the font metrics are a feature of the typeface itself, so if you're specifying an .otf or .ttf font using @font-face, you gain control over this. See this thread, you can edit the font and change the "Really use typo metrics" flag of the font file. That's the "right" solution, but it only works if you want to serve your own font files. If not, just specify a font that renders the same across browsers.

CSS font differences between browsers

Even with identical CSS rules and identical font files you will never have exactly identical rendering:

1. modern font formats are composed of layers of overlapping instructions, where the "new better" way does not replace previous iterations, but is present in addition to those. The advantage is that old software can still read the old-style instructions and work as before. The disadvantage is that the same property is described in many different ways and they do not give the same results (you'd think the newest layer would give the best results but the font designer may have only extensively tested and debugged an older one)

2. to add insult to injury some are system-specific (Windows, OS∕2, OSX…) so even the same generation of software won't read the same instructions depending on the target system

3. lastly even if a font only contained a single instruction layer, and all your browsers read it completely, they would have some leeway in interpreting it. On an ideal retina screen with high pixel density they'll all use the same shapes and coordinates, but actual screens have too low pixel densities to display small complex text shapes accurately. So the text engines have a choice between displaying sharp but jaded lines (distorting the glyph shapes so they snap to a monochrome pixel grid) or smooth but blurry lines (approximating ideal shapes by playing on pixel grayness level or even subpixel colors). Those adjustments will move text pixels around.
   
   Depending on the system text rendering conventions are not identical. OSX will lean towards smooth blurry rendering, Windows towards sharp jaded rendering, and the Linuxes cover all the choices in-between.

4. And of course, even on the same system the same software won't make the same choices depending on the quality (pixel density) of the hardware available.

For some insight on all the possible rendering strategies a text engine can choose see

https://docs.google.com/document/d/1wpzgGMqXgit6FBVaO76epnnFC_rQPdVKswrDQWyqO1M

You can not usually control the text rendering compromise chosen by the browser from your web site. Even if you could forcing windows-style rendering on osx (or the reverse) would only annoy uses that want your web site to behave like all the other text they see on their screen. And in fact, the more tolerant your web site will be to browser's font rendering choices, the better it will be. A web site is dynamic. A web site can reflow. Pixel-perfect is not a user ideal. If you want pixel-perfect, serve them a bitmap image, and you'll quickly see how much it is appreciated.

Therefore, only use @font-face for specific design effects, and not to try to force a specific text pixel placement on your site. The first will work beautifully. The second, not at all. If you use @font-face do remember fonts are covered by copyright so sharing any font requires legal permission.

PS. Helvetica is an old font design. It has been derived so many times requesting 'Helvetica' on different systems will yield a plethora of results. So this is a font that can not be used on the web without @font-face.

fonts opentype text-rendering

Why does Firefox treat Helvetica differently from Chrome?

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

CSS @font-face not working with Firefox, but working with Chrome and IE

LOCALLY RUNNING THE SITE (file:///)

Firefox comes with a very strict "file uri origin" (file:///) policy by default: to have it to behave just as other browsers, go to about:config, filter by fileuri and toggle the following preference:

security.fileuri.strict_origin_policy

Set it to false and you should be able to load local font resources across different path levels.

PUBLISHED SITE

As per my comment below, and you are experiencing this problem after deploying your site, you could try to add an additional header to see if your problem configures itself as a cross domain issue: it shouldn't, since you are specifying relative paths, but i would give it a try anyway: in your .htaccess file, specify you want to send an additional header for each .ttf/.otf/.eot file being requested:

<FilesMatch "\.(ttf|otf|eot)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"
    </IfModule>
</FilesMatch>

Frankly, I wouldn't expect it to make any difference, but it's so simple it's worth trying: else try to use base64 encoding for your font typeface, ugly but it may works too.

A nice recap is available here

Special characters rendering off place in Firefox

The problem is likely that you are using the 'COMBINING ACUTE ACCENT' (U+0301) along with the U character instead of the 'LATIN SMALL LETTER U WITH ACUTE' (U+00FA) Ú.

The former character set is not in your font so the browser has to use an other system font, which is why it may not render correctly. You can check this in the font panel of your dev-tools.

However, your font does have the Ú character, so if you fix it in your markup, you should be good in all browsers.

@import url('https://fonts.googleapis.com/css?family=Archivo+Black');body{  font-family: 'Archivo Black', sans-serif;}

<div>MÚSICA (U +  ́ )</div>
<div>MÚSICA (Ú)</div>

Why does Firefox treat Helvetica differently from Chrome?

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

---

Related Topics