Closed Bug 1204057 Opened 10 years ago Closed 10 years ago

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]

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Version:
40 Branch
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 816948

People

(Reporter: DavidCharlap, Unassigned)

References

(
URL
)

Details

(Whiteboard: [gfx-noted])

Attachments

(3 files, 4 obsolete files)

Test-case for font-size inflation
198 bytes, text/html
Details
Test-case rendered with minimum font size of 9
82.47 KB, image/png
Details
Test-case rendered without a minimum font size
75.10 KB, image/png
Details
Attached image Apple support - Firefox 40.png (obsolete) —
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.
This is approximately how the page should be rendered.
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".
URL: https://support.apple.com/en-us/HT201257
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Component: Untriaged → Graphics: Text
Product: Firefox → Core
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.
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)
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]
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.
Attachment #8660022 - Attachment is obsolete: true
Attachment #8661458 - Attachment is obsolete: true
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
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: