New issue
Advanced search Search tips

Issue 623842 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Setting monospace on a parent can cause sans-serif children using rem units to increase in size

Reported by mcbain....@gmail.com, Jun 28 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Set font-family: monospace; on an element with a child using font-family: sans-serif; font-size: 1rem; 

What is the expected behavior?
The sans-serif child with the font-size of 1rem should have the same computed pixel size as text using the root font-size. By default this is 16px.

What went wrong?
The sans-serif child with the font-size of 1rem have a font-size of 19.6923px

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 51.0.2704.106  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 22.0 r0

The bug doesn't occur for children that inherit the font-family from the parent (stay monospace). I also tested this in Firefox and IE where the result is as expected. The inner div has the right font-size regardless of the font-family.
 
chrome-fontsize-rem-testcase.html
1.0 KB View Download
chrome-fontsize-rem-extremelyminimal-testcase.html
505 bytes View Download
Components: Blink>Fonts
Labels: -Type-Compat M-53 OS-Linux OS-Mac Type-Bug
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.5 using chrome versions 51.0.2704.106 and canary 53.0.2782.0.Observed the font sixe of sans-serif child with the font-size of 1rem is 19.6923px instead of 16px.
This is non regression issue as the issue is seen from M30 builds.
Marking it as Untriaged to get more inputs from dev team.

Thanks,

Comment 2 by e...@chromium.org, Jun 30 2016

Cc: drott@chromium.org kojii@chromium.org
Status: Available (was: Untriaged)
Project Member

Comment 3 by sheriffbot@chromium.org, Jul 2 2016

Labels: -M-53 M-54 MovedFrom-53
Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 4 by sheriffbot@chromium.org, Jul 3 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by e...@chromium.org, Jul 6 2017

Status: Available (was: Untriaged)
Project Member

Comment 6 by sheriffbot@chromium.org, Jul 9

Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)
Related discussion at https://github.com/w3c/csswg-drafts/issues/1835
I know this is old and deemed unimportant, but as the issue still exists, I'd like to note that though the above W3C link is related, I believe it to be unimportant to this bug.

What I reported above uses neither relative keywords (medium, larger, etc.) or em units.

https://www.w3.org/TR/css-values-3/#rem
https://www.w3.org/TR/css-values-4/#rem

In the spec, 1rem should be equal to the root font-size, ignoring any changes to the size in between, seemingly regardless of whether it was specified by a font-family or font-size change. Therefore I still think the expected behavior should match that of Firefox and IE/Edge (prior to the Chromium switch).

Sign in to add a comment