The size of the 'rem' unit should not be inflated by the minimum font-size setting [was: Fonts on Apple support page rendering far too large]

RESOLVED DUPLICATE of bug 816948

Status

()

Core
CSS Parsing and Computation
RESOLVED DUPLICATE of bug 816948
3 years ago
2 years ago

People

(Reporter: David Charlap, Unassigned)

Tracking

40 Branch
x86_64
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted], URL)

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

3 years ago
Created attachment 8660022 [details]
Apple support - Firefox 40.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150826023504

Steps to reproduce:

Visit https://support.apple.com/en-us/HT201257

The problem is seen on every one of Apple's KB pages (e.g. http://support.apple.com/kb/HT5781 and many more)


Actual results:

The fonts on the page's main body are rendered far too large.  One word of text can fill the entire screen unless I zoom all the way out, and even then it's still too large.

See the attached image.


Expected results:

They should render at a normal reading size.  They do render correctly with Internet Explorer.
(Reporter)

Comment 1

3 years ago
Created attachment 8660023 [details]
How the same page renders using Internet Explorer 9

This is approximately how the page should be rendered.
(Reporter)

Comment 2

3 years ago
This was seen using Firefox 40.0.3 on Windows 7.

It was also seen on Iceweasel version 38.2.1 on Debian Linux "Jessie".
(Reporter)

Updated

3 years ago
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64

Updated

3 years ago
Component: Untriaged → Graphics: Text
Product: Firefox → Core
(Reporter)

Comment 3

3 years ago
After a few more tests, the problem only seems to occur when my font preferences has a minimum font-size configured.  I normally have my minimum font size set to 9 points.  This causes the specified page to end up with gargantuan fonts, which makes no sense because those fonts are much much larger than 9 point.

I noticed that I get strange (but different) text rendering on Apple Safari when I have it configured for a minimum font size.  (With Safari, I don't see huge fonts, but characters overlap each other and they have a huge indent from the left-edge, pushing most of the text off of the right side of the screen.)  Disabling minimum font size fixes it there as well.

At this point, I don't know if we're looking at a Firefox bug or a problem with Apple's CSS.  Or maybe a bit of both.  But hopefully someone with knowledge of the Firefox text rendering engine will know what to investigate.
(Reporter)

Comment 4

3 years ago
Created attachment 8661457 [details]
Firefox 40.0.3 - Mac OS X 10.10.  No minimum font size configured.
(Reporter)

Comment 5

3 years ago
Created attachment 8661458 [details]
Firefox 40.0.3 - Mac OS X 10.10.  Minimum font size set to 9

Now that I know it's triggered by the minimum font size, I'm uploading two new images (Firefox 40.0.3, Mac OS X 10.10) rendering the same page with the minimum size set to none and to 9.

I'm obsoleting the IE9 image, since that's a red herring and no longer necessary as an example of what the page should look like.  I'm leaving the original image (Firefox 40.0.3 on Windows) in order to show that the bug is cross-platform.  (Now demonstrated on Windows, Mac OS X and Linux.)
Attachment #8660023 - Attachment is obsolete: true
Jonathan, any ideas?
Flags: needinfo?(jfkthame)
Whiteboard: [gfx-noted]
A code path that doesn't know the minimum font size is already in app units?
Does this problem still occur? I can't seem to reproduce it here, even with a minimum font size set -- I think Apple has recently modified the styling of these pages.

The issue was triggered by their use of a slightly quirky styling technique: IIRC, the root <html> element was given font-size:1px, and then all the various elements of text were given font sizes expressed in terms of "rem" (root em) units; e.g. the main heading might be given font-size:40rem, or thereabouts.

That was fine if there was no minimum font size in effect, but if a minimum of 9px (for example) was applied by the browser, the "root em" unit suddenly becomes 9px instead of 1px, and so that heading becomes 360px instead of the expected 40px.

So that's what I believe was happening, but AFAICS the stylesheets have been changed and the issue no longer exists.
Flags: needinfo?(jfkthame) → needinfo?(DavidCharlap)
(Reporter)

Comment 9

2 years ago
It would appear that Apple changed their CSS to fix the problem.  I just checked using Mac OS X and Windows 7 and the problem is not happening now.

So I think this specific bug can be closed, but it might be worthwhile to prepare a page that reproduces the problem and open a new bug to track that.  If it is as your suspect, then would it be considered a bug?

My gut feeling says that if a page does this, the minimum font-size check should be done a the end of the transformation chain and not at intermediate steps.  For example, if the root is 1px, and then there is text specified as 2rem through 50rem, and I've got a minimum font size of 9px, then I would expect the page to be rendered as 9,9,9,9,9,9,9,9,10,11..50 and not as 18,27,36..450

On the other hand, I can understand the argument that the 1px at the root is a terminal size and that "rem" should be is relative to what actually got rendered.  To which I could only argue "even if it makes the page impossible to read?"
Flags: needinfo?(DavidCharlap)
(In reply to Jonathan Kew (:jfkthame) from comment #8)
> Does this problem still occur? I can't seem to reproduce it here, even with
> a minimum font size set -- I think Apple has recently modified the styling
> of these pages.
> 
> The issue was triggered by their use of a slightly quirky styling technique:
> IIRC, the root <html> element was given font-size:1px, and then all the
> various elements of text were given font sizes expressed in terms of "rem"
> (root em) units; e.g. the main heading might be given font-size:40rem, or
> thereabouts.
> 
> That was fine if there was no minimum font size in effect, but if a minimum
> of 9px (for example) was applied by the browser, the "root em" unit suddenly
> becomes 9px instead of 1px, and so that heading becomes 360px instead of the
> expected 40px.
> 
> So that's what I believe was happening, but AFAICS the stylesheets have been
> changed and the issue no longer exists.

It was happening as of just yesterday for me. So, it must have been changed on their end sometime between yesterday and today. But what you describe sounds like exactly what I was seeing in the inspector when looking at the text, at least with regard to gigantic rem sizes that made no sense.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
(In reply to David Charlap from comment #9)
> ...
> 
> My gut feeling says that if a page does this, the minimum font-size check
> should be done a the end of the transformation chain and not at intermediate
> steps.  For example, if the root is 1px, and then there is text specified as
> 2rem through 50rem, and I've got a minimum font size of 9px, then I would
> expect the page to be rendered as 9,9,9,9,9,9,9,9,10,11..50 and not as
> 18,27,36..450

That sounds like a reasonable approach.  Probably a good first bug?
(In reply to David Charlap from comment #9)
> It would appear that Apple changed their CSS to fix the problem.  I just
> checked using Mac OS X and Windows 7 and the problem is not happening now.
> 
> So I think this specific bug can be closed, but it might be worthwhile to
> prepare a page that reproduces the problem and open a new bug to track that.
> If it is as your suspect, then would it be considered a bug?
> 
> My gut feeling says that if a page does this, the minimum font-size check
> should be done a the end of the transformation chain and not at intermediate
> steps.  For example, if the root is 1px, and then there is text specified as
> 2rem through 50rem, and I've got a minimum font size of 9px, then I would
> expect the page to be rendered as 9,9,9,9,9,9,9,9,10,11..50 and not as
> 18,27,36..450
> 
> On the other hand, I can understand the argument that the 1px at the root is
> a terminal size and that "rem" should be is relative to what actually got
> rendered.  To which I could only argue "even if it makes the page impossible
> to read?"

Well.... checking the CSS Values spec[1] we find that 'rem' is "[e]qual to the computed value of font-size on the root element." And AFAICT, the computed value of font-size does not take account of any minimum font size that may have been specified in the preferences.

Which seems to suggest that your expectation is correct, and there is a Gecko bug here in the computation of the 'rem' unit.

Testcase:
  data:text/html,<html style="font-size:1px">
    <span style="font-size:6rem;border-left:1rem solid red">hello
    <span style="font-size:12rem;border-right:1rem solid green">world

Result: with no minimum font-size set, the word "hello" should be in 6px type (barely readable), and "world" in 12px; the red and green borders at the ends should be 1px thick.

Setting minimum font-size to 9 should inflate the word "hello" to 9px, and leave the rest of the sizing unchanged. But it actually inflates everything by 9 times.


[1] http://www.w3.org/TR/css3-values/#font-relative-lengths
Component: Graphics: Text → CSS Parsing and Computation
Summary: Fonts on Apple support page rendering far too large → The size of the 'rem' unit should not be inflated by the minimum font-size setting [was: Fonts on Apple support page rendering far too large]
(Reporter)

Comment 13

2 years ago
Created attachment 8664242 [details]
Test-case for font-size inflation

Thank you very much for a testcase.  I confirmed it locally.  I'm attaching a trivia HTML file containing your example, so developers can use it as a part of confirming when the bug has been fixed.
(Reporter)

Comment 14

2 years ago
Created attachment 8664244 [details]
Test-case rendered with minimum font size of 9
Attachment #8660022 - Attachment is obsolete: true
Attachment #8661458 - Attachment is obsolete: true
(Reporter)

Comment 15

2 years ago
Created attachment 8664245 [details]
Test-case rendered without a minimum font size
Attachment #8661457 - Attachment is obsolete: true
Re comment 12:  The minimum font size preference is effectively an out-of-band user stylesheet, so I think it should affect the compute value.

I think for correct uses of 'rem', our current behavior does make sense.  If a page's root element's font size is too small for the user to read and they've increased it, then if they've sized other things relative to that font size, those things should increase since the author asked for them to be relative to the root element's font size.

When people are sizing the root to 1px and then using rems everywhere else to mean px -- well, that's not the intended use of 'rem'.

I think it's worth considering a change in the behavior if it's a major compatibility problem, but this site appears to have been fixed.

I suspect there's also an existing bug somewhere on the topic.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 912493
Duplicate of bug: 816948
You need to log in before you can comment on or make changes to this bug.