816948 - rem units are relative to the font size after font.minimum-size preference is applied

Status: REOPENED

(Core :: Layout, defect)

Description

[Octoploid]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20.0 Firefox/20.0
Build ID: 20121128171840

Steps to reproduce:

Set font.minimum-size.x-western to 15.
Go to e.g.: http://home.web.cern.ch/scientists


Actual results:

The displayed font is way too big (I would guess over 20).


Expected results:

Show the font with the specified size of 15.

Comment 1

[Octoploid]

Ugh, it's the new font-size rem craziness that's spreading all over the net.

I had to add:
p  {
  font-size: 1.1rem !important;
}
to userContent.css to get numerous sites back to sanity.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We base 'em' units on size with the min font size applied.  So I think it makes sense to do the same for 'rem', though we have the option of changing (using ->mSize rather than ->mFont.size).

Comment 3

[Octoploid]

(In reply to David Baron [:dbaron] from comment #2)
> We base 'em' units on size with the min font size applied.  So I think it
> makes sense to do the same for 'rem', though we have the option of changing
> (using ->mSize rather than ->mFont.size).

I think this would be a good idea. Do you have a patch that one could try?

BTW another good example page is http://www.economist.com/ .

Comment 4

[Octoploid]

Attachment: mSize patch

Comment 5

[Octoploid]

Attachment: screenshot before patch was applied

Comment 6

[Octoploid]

Attachment: screenshot after patch was applied

Comment 7

[Octoploid]

The attached patch fixes the issue for me.
For comparison I've attached two screenshots (before, after).
font.minimum-size.x-western was set to 15.
The Font is Swift from Gerard Unger.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

As far as the patch -- it's reasonable, except you'd also want to make the same change a few lines up, in the previous part of the if-else if-else chain.  (And patches with more context are good too.)

That said, I still don't understand the rationale for this change, though I haven't had a chance to debug the sites you're citing and play with the behavior with and without patch on them (and probably won't have a chance to do that for the foreseeable future).

What are these sites doing such that this patch even has an effect?  (I'm assuming that you have the default font size preference still set to 16 along with setting the minimum size preference to 15 -- or maybe that's not the case?)  Are they setting a root font size that's substantially smaller than any size they actually use on the page, and then using >1rem measures everywhere else?

Comment 9

[Octoploid]

Basically they are setting:
html {
    font-size: 62.5%;
}
and use >1 rem measures everywhere else.

(My default font size is set to 12 and the minimum size to 15)

Comment 10

[Octoploid]

Attachment: Use mSize instead of mFont.size in CalcLengthWith

Comment 11

[Octoploid]

Ping!

Comment 12

[Octoploid]

Attachment: Updated patch (for trunk)

Comment 13

[Rotis]

On Usenet someone posted another example URL for this bug:
http://aufdurchreise.com/
Octoploid's workaround (comment #1) helps!

Comment 14

[Octoploid]

No review for half a year, closing.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 718875 [details] [diff] [review]
Updated patch (for trunk)

I don't think having the default font size set smaller than the minimum font size is a sensible configuration.  Perhaps we should even enforce that?

And I really think that 'rem' and 'em' units should be responsive to user configuration that changes the font size; that's sort of the point of the units.

Sorry for not saying so sooner, though.

Comment 16

[Alice0775 White]

http://www.sankei.com/ is also affected.
Minimum font size set to 16 in Japanese, all fonts are ugly bigger.

Google chrome is good implementation.

Comment 17

[Octoploid]

Yeah. I'm still using my patch locally...

Comment 18

[Octoploid]

Attachment: yandex login screen without patch

Comment 19

[Octoploid]

Attachment: yandex login screen with patch applied

Comment 20

[Octoploid]

Attachment: yandex login screen chrome

Comment 21

[Alice0775 White]

What is problem the patch?
Spec? 
Try build test failure?

Comment 22

[Octoploid]

(In reply to Alice0775 White from comment #21)
> What is problem the patch?
> Spec? 
> Try build test failure?

Well, the patch fixes the issue.

Please also note that the minimum font size and the default font size are equal (14) 
in the yandex screenshots.

Comment 23

[Alice0775 White]

Minimum font size set to 16 in Japanese, all fonts are ugly bigger.
In addition to Comment 16,

http://www.plus-blog.sportsnavi.com/tennisgs/article/531
http://yuapon38.net/
http://matsuzakiseikotsuin.com/voice
http://koa-labo.com/
http://design-spice.com/
http://hollywet.co.jp/archives/category/blog
http://stack3.com/web-design/css_font_family_body.html
http://w3q.jp/
http://fontplustips.com/
http://negimemo.net/
http://bakupaka.com/smf/%e3%82%b9%e3%83%9e%e3%83%9b%e3%82%b5%e3%82%a4%e3%83%88%e3%81%ae%e6%96%87%e5%ad%97%e3%82%b5%e3%82%a4%e3%82%ba%e3%81%af%e3%80%8crem%e3%80%8d%e3%81%8c%e3%81%8a%e3%81%99%e3%81%99%e3%82%81%e3%80%82/
http://yattoko.com/menu-drink

Comment 24

[Ravi Nimmagadda]

Test

Comment 25

[Ravi Nimmagadda]

Test

Comment 26

[Boris Zbarsky [:bzbarsky]]

Is this also a duplicate of bug 912493?

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Note that there are extensive discussions in both of those duplicates.


In bug 1204057 comment 16, I wrote:

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.

Comment 30

[Jonathan Kew [:jfkthame]]

I'm not sure which behavior I think is more "correct"... I can imagine arguments either way.

One point of view might be that setting a minimum font-size preference means the user is asking to override the page author's styling, where necessary, to ensure that fonts never get too small -- while not necessarily scaling other things in proportion. (For that, Page Zoom would be the obvious approach.) So then the minimum should apply to the used value of font-size, but not to the computed value that may be inherited by other elements, scaled further by use of 'em' or percentage sizes, etc.

This makes it feel a bit like "font inflation" on mobile, which inflates small fonts but leaves larger ones untouched (though its effect tails off gradually, rather than having a flat "floor").

Inspecting the root element indicates that the minimum is not reflected in the computed value of font-size, which means that our implementation of 'rem' differs from the CSS Values spec: we're taking the used value, rather than the computed value as the spec requires.

If we intend to keep the current behavior, therefore, we should probably raise this as a spec issue.

In Chrome, FWIW, the computed font-size of the root element does take account of the minimum font size; but the 'rem' unit uses the specified value from the root, without the minimum applied -- so they're out-of-spec, too, but in the opposite way! (Sigh.)

Comment 31

[Sebastian Mathis]

David Baron described in Bugticket 912493 "setting the font-size of the html-element to 62.5% or to 10px, then decreasing or increasing this attribute in media-queries as a poor technique".
I would strongly argue against that opinion. First of all I would like to discuss what rem-units are good for. I would guess most time rem-units are used to adjust font-size and sizes in general in media-queries relative to the width to the main body content (which I can achieved by setting font-size by a non-relative unit eg. px). I absolutely can't see why this should be poor technique. In the best of all worlds indeed websites would be designed in a way that sizes, colors, font-families etc. all do not matter. But world is not like this. I have to define sizes relative to each other, and not at least I pretty often have to define the sizes relative to the view-port size. Why shouldn't I use rems for that (it's definitely the better approach then using vw and vh-units). The idea, that font-size is always the clients decision is nothing more then ideology. The intention of a user setting a minimum-font-size, is not to change the design of a page in general, but to prevent the browser to display text in a size the user can't read. 99% of the users have no idea of root-ems, they have no idea that setting minimum-font-sizes might end up getting pages displayed bigger. 
As a developer I ended up with the solution to set the font-size of the root-element to 50px for large-screen so I can divide all sizes through 4 (by changing font-size of the root-element) without being affected by the firefox-font-size default settings. It works but it is somehow crazy.

And no, I guess there is no spec issue, it is a conflict of ideologies. 

Arguing that this bug is no real issue, because all mentioned pages have fixed the compatibility problems is no argument at all. It just shows that there are still a few developers who care about firefox-users...
Please seriously consider changing the described behaviour of firefox.

Comment 32

[zcyzcy88]

Demo: https://codepen.io/anon/pen/eRpxNW

There are spec(https://www.w3.org/TR/css3-values/#rem) for "rem unit" but no spec for "minimum font size".

Then become another question:
Consider "apply minimum font size" as computing process or individual process?

If "computing process", Chrome version breaks rem definition.


Firefox version:
1- declare
2- compute and apply minimum font size in computation
3- compute based on computed root and apply minimum font size in computation
4- render

Chrome version:
1- declare
2- compute
3- compute based on computed root
4- apply minimum font size (individual)
5- render

Comment 33

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 34

[Mikael Willberg]

I think this needs to gain a bit more momentum as more and more clueless webdevs are jumping on the "10px static body with rems that are so cool, but we'll use tham just like oldschool px" train.

I mainly use chrome for keeping google tracking limited to their browser and sites. Just wondered to youtube.com with my main browser and everything is huge.

I have minimum fontsize of 16px and the following should be rendered with decent 18px size.

=============
font-size: 25.2px;

element
HTML[0].style
10px

inline:1
.title.ytd-video-primary-info-renderer
var(--ytd-video-primary-info-renderer-title-font-size, 1.8rem)

html.css:176
h1>2em
=============

Comment 35

[Mikael Willberg]

Sorry, can't edit a little error, all my font.minimum-size.* are 14px.