1687505 - line-height calculation is broken

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect, P4)

Description

[Arnold]

Attachment: line-height-failure.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

The Firefox handling of line-height CSS is broken, and has been so ever
since Quantum (Firefox 57).

The problem appears to be that the physical line height (as measured in
pixels) is calculated early on, based on what is then known about the
font size at that moment. And then when further changes are made to
the font size, the line height is not recalculated to be based on the
actual as-displayed font size. The net effect in the following test
case is that one ends up with lines of overlapping text, which is not
at all what is desired.

What should happen instead is that the line-height calculation should
occur at the end of the processing, after all adjustments that affect
the actual displayed font size.

Here is a simple test.

• Set the browser preferences as follows;

  • Default font, size 14.
  • Minimum font size, none.
  • Allow pages to choose their own fonts, instead of your selections above, unchecked.
  • View > Zoom > Zoom text only, disabled.

• Display the attached line-height-failure.html file in Firefox.
  (I'm testing this right now in 84.0.2, Linux 64-bit.)

• Use Ctrl-mousewheel to change the font size through the full range of
  available sizes, from tiny to large. Observe that at all font sizes,
  the leading (line-height) remains properly proportional to the displayed
  font size, and the text remains legible (if not actually readable at
  the smallest sizes), because successive lines remain distinct on-screen.

• Change the browser preferences as follows:

  • Default font, size 9.
  • Minimum font size, 16.

• Use Ctrl-mousewheel to change the font size through the full range of
  available sizes, from tiny to large. Observe that at all font sizes,
  successive lines overlap slightly, because the line height actually
  used for display is somehow no longer based on the actual as-displayed
  font size. In fact, it's apparently impossible for a developer to
  actually know what the displayed line height is based on in this case.

• Toggle the "View > Zoom > Zoom text only" setting to enable it, and run
  through the range of font sizes again. Observe how the line height
  is no longer proportional to the displayed font size at the smaller
  end of the range, because (it seems) the line height is calculated
  before the minimum font size is imposed.

I know there are many measurement units one can use for CSS line-height
(px, em, rem, ...), so you might believe this is complicated beyond what
this one test case shows. But I suspect you don't need to overthink this.
Just move the final calculation of the displayed line-height to the end,
after all font-size adjustments (like a minimum font size) have been made.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

This is not so easy. Making em units resolve against the used font-size causes lots of broken pages. In fact Chrome had to align with Firefox for that reason.

For the particular case of the line-height property though, you can use line-height: 1.2 instead, which will take into account the used font-size, not the computed one.

Comment 2

[Arnold]

I would strongly urge you to reconsider. This bug report is definitely not "invalid". When you say, "you can use line-heignt: 1.2", you are missing the point. This is not just about what I do within my own pages; it's about what happens all over the Internet, on sites that I do not personally control. As a quick example, try the same experiments on the front page of https://www.nytimes.com/ . You'll see it has the same problem. I only supplied you with a cut-down test file so you could more easily use that to test the bug fix, not because the problem is specific to documents I am constructing. Quantum broke this, when it was working before that.

Comment 3

[Arnold]

Not to be impolite, but I am moving this bug back to UNCONFIRMED status, to try to ensure that my previous comment gets considered and is not overlooked. You have given no proof that a fix for the problem would cause lots of broken pages, when in fact I see lots of broken pages on the Internet as it stands. This is in fact the single most-broken part of Firefox I experience in my daily use of the browser.

If you resolve the bug report in an unfavorable way again, I will desist, and not be a pest about it. Just be aware that in the process, you will be destroying my motivation to contribute more bug reports in the future.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I mean, I sympathize with the use case, and really appreciate the quality report. However fixing this would break more than it actually fixes, see the issues referenced here for example.

We could maybe special-case line-height from other em units, but that'd create even more inconsistencies.

Comment 5

[Jonathan Kew [:jfkthame]]

I'm pretty sure I've also seen other types of web-page "breakage" when a minimum font size is applied -- especially if the minimum is set large enough that it affects substantial blocks of text. Unfortunately that seems to be a risk that comes with the feature, as it interferes with sizing relationships that authors (rashly) assume they can rely on.

Comment 6

[Jonathan Kew [:jfkthame]]

So as Emilio has explained, it's not clear that there is a "better" solution available here. The Chrome experience (comment 1) suggests they reached the same conclusion.

I'm sorry to hear this results in "lots of broken pages" (comment 3) for you, I'm sure that's frustrating. Maybe things would be "less broken" if instead of a large minimum font size, you used a larger default zoom ratio to ensure small text is readable? This may be less likely to disrupt sites' layout in ways that the designer didn't anticipate and handle.

Comment 7

[Mats Palmgren (inactive)]

Making em units resolve against the used font-size causes lots of broken pages. In fact Chrome had to align with Firefox for that reason.

I agree that's a non-starter.

I do think we have a pretty broad license (from the user) to do whatever works for them when they have set the minimum font size preference though. We could for example simply ignore all author line-height declarations if that would work better with this pref. Would that be an improvement?

Comment 8

[Mats Palmgren (inactive)]

This bug report is definitely not "invalid".

As a Bugzilla resolution, that word only means "this works as intended". You shouldn't read it as a judgment on your report. As Emilio said above, we appreciate detailed quality reports like this. (Personally, I really wish we could change it to a word that sounds less harsh, but I suspect that's been discussed already...)