New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 319623 link

Starred by 66 users

Issue metadata

Status: Fixed
Closed: Jan 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

REM units are not applied correctly to <body>

Reported by, Nov 15 2013

Issue description

Chrome Version       : 31.0.1650.48
URL : (See attached test page)
Behavior in Safari 4.x/5.x: Text renders proper size, doesn't change
Behavior in Firefox 3.x/4.x: Text renders proper size, doesn't change

What steps will reproduce the problem?
1. Open the web page
2. Open Chrome web inspector -- notice that >50% of the time the font resizes

I believe this is related to the HTML element having a % font-size assigned to it and using REMs in combination with it.

249 bytes View Download
incorrect initial render.png
49.3 KB View Download
correct font size.png
48.9 KB View Download

Comment 1 by, Nov 15 2013

Labels: Cr-Blink-CSS

Comment 2 by, Nov 19 2013

I am seeing this too. see attached.
163 KB View Download

Comment 3 by, Nov 19 2013

This just started happening recently, I do have a font size in % on html, and font size in rem on the body. Works fine in FF and IE. 

Comment 4 by, Nov 19 2013

Duplicate of #320754
 Issue 320754  has been merged into this issue.
Labels: -Type-Compat Cr-Blink-Rendering
stwest79, Thanks for filing this issue. Are you still seeing this with Latest Stable#31.0.1650.57 as well?
Labels: Needs-Feedback

Comment 8 by Deleted ...@, Nov 19 2013

I am experiencing this issue as well. I also use % in combination with REM-sizes. I attached a test html page. When I open the developer tools and reload the page the font-size changes.
318 bytes View Download
I am experiencing the same problem with the use of REM sizing with px fallback. It used to be working properly before Chrome 31.

Comment 10 by, Nov 19 2013

My screen shot above is from 31.0.1650.57 m

Comment 11 by, Nov 19 2013

Still happening in 31.0.1650.57 on the submitted HTML test page (test.html)

Comment 12 by, Nov 19 2013

Moving the font-size away from the HTML is a valid work around, by either applying it to the body or other elements.
As mentioned here :

I also noticed this font-size problem.
It seems this issue occurs only with web native fonts and is not reproductible with the use of font-face.
@pierre : I am having this issue with the "Lato" Google Webfont.

Comment 16 by, Nov 20 2013

As stated here for me it seems to happen with font-sizes that are smaller than the browser default.

If the browser default is 16 (no unit is given but I think it's pixels) and you set a font-size of < 100% or < 16px on the html, the browser seems to get it wrong when using rems later on.
Labels: -Needs-Feedback OS-All
Status: Untriaged
This is reproducible in all the channels latest dev 33.0.1707.0/ stable 31.0.1650.57 and latest beta 32.0.1700.14
it's also reproducible in all the OS. making it as non regression issue.
Certainly not just an issue with percentage bases. I've got a base of 10px on html and having this problem also
You can see this issue on websites using rem like

Comment 20 by, Nov 29 2013

I can confirm the issue. We have similiar problems. We use: 

html { font-size: 62,5%; }
body { font-size: 1.2rem; }
Behavior occurs on latest Chrome for Android (31.0.1650.59) and latest Chrome for OS X (31.0.1650.57). Pretty significantly affects many sites.
 Issue 325697  has been merged into this issue.
I believe this issue happens regardless of percentage font-size, but when you have a font-size defined in the html before using rem in the body.

I tried using font-size: 10px on the html and it also doesn't work.

It appears to be ok on Chrome Canary, though.

Comment 24 by, Dec 19 2013

In my experience, changing the font-size to a px value on the html element (or removing font-size entirely) had no effect. My workaround is:

html { font-size: 62.5%; }
body { //no font size declared, but setting a px value worked for me too }
p, li { font-size: 16px; font-size: 1.6rem; }

I see a similar issue with my browser
I have a similar issue, this also seem to appear in the chrome browser on android (4.4). For a workaround i use:

html {font-size: 62.5%; }
*:not(html) { font-size: 1.2rem; }

where *:not(html) replaces the body font-size.

Comment 27 by Deleted ...@, Jan 22 2014

I'm noticing this issue also.

I'm also using a percentage for the HTML tag and REMs everywhere else.
Labels: Cr-Blink-Fonts Cr-Blink

Comment 29 by, Jan 23 2014

Labels: Needs-Bisect

Comment 30 by, Jan 23 2014

Status: Assigned
u can wail till emil looks before we bisect.

Comment 31 Deleted

I was able to reproduce with - Hitting run repeatedly would occasionally cause a font size failure. It would happen all the time on reload vs refresh, but that might be a different cause.

Comment 35 by, Jan 23 2014

Separate issue, please go ahead and bisect.
Labels: -Needs-Bisect
Ran a manual bisect, looks like it was the following change:

Subject : When there are no more stylesheets schedule the recalc async
Author  :
Link    :
Commit  : 33c8b55d6d6ed5bf362074532a835903bcd9453b
Date    : Tue, 10 Sep 2013 04:19:33 +0000
Summary: REM units are not applied correctly to <body> (was: Rendering issue when using % + REMs in CSS)
Reduction, this isn't an issue with percents, it appears to be specific to using rem units on the body.

<!DOCTYPE html>
html { font-size: 30px; }
body { font-size: 1rem; }
This should be 30px tall.

rune@ any ideas? :)
Project Member

Comment 40 by, Jan 27 2014

The following revision refers to this bug:

r165831 | | 2014-01-27T04:51:19.617909Z

Changed paths:

CSS rem units should properly resolve on <body>

When we introduced Document::inheritHtmlAndBodyElementStyles in r157174
we made recalcStyle start calling into StyleResolver::styleForElement
on the body while the documentElement may have needed to reattach. This
would add the body's style to the matched property cache with rem units
resolved against a stale documentElement style (or the root style) and
then later inside Element::recalcOwnStyle we'd get the wrong value for
the <body>'s style since we'd pull the bad value back out of the cache.

This could manifest even before r157174 if you changed the font size of
the <html> element through script and also its display at the same time.
In that case we'd go down the attach path and never get to the font size
checks for the documentElement that were inside Element::recalcOwnStyle.

This patch moves the font size checks into inheritHtmlAndBodyElementStyles
and adds a case for when reattaching the documentElement. This is not
optimal since changing the display of the <html> element when using rem
units shouldn't need to clear the whole matched properties cache, but
reattaching the <html> element is also very rare so this is probably fine.

In the future we could track which elements are affected by rem units and
invalidate only those elements and clear only those cache entries like
we do for viewport units to improve upon this.

BUG= 319623 

Review URL:
Is there an expected release version set to include this patch yet?
Labels: M-34
Status: Fixed
 Issue 296380  has been merged into this issue.
@alheureux This should be fixed in M34.

Comment 45 by, Mar 25 2014

I'm still able to repro this on Chrome 34.0.1847.76 beta as long as the CSS is in an external stylesheet.
205 bytes View Download
61 bytes View Download

Comment 46 by, Apr 10 2014

In fact, Chrome rem as a unit with all the places there are problems, it is strongly recommended that a complete test and fix the problem. For example: width, height, padding ...
743 bytes View Download
Please file a new bug for your issue.

Comment 48 by, Apr 10 2014

(not sure if you were talking to me :) )

Comment 49 by Deleted ...@, May 3 2014

I just want to point out the most obvious workaround for this issue, for anyone who has stumbled into this thread. There's no need for universal selectors or using pixels:

Just don't use rem in the body style declaration. You can use em in place of rem and it won't affect your other styles in any way. You can revert back to using rem for everything within your body. The whole point of rem is to refer to the font-size of your root element (your html style declaration).
Unfortunately, this bug appears to be present in the build of Chromium used to run webviews within Android 4.4.

And now it will need to be supported with workarounds until that version of the OS loses sufficient market share =|
Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout

Comment 52 by, Mar 10 2015

I concur that #49 is a suitable workaround until this bug fixed. Using 'em' on the body and 'rem' everywhere provides the same functionality as 'rem' everywhere (including the body) with no side-effects.

Comment 53 by Deleted ...@, Nov 6 2015

I am experiencing an issue where the font size on a before element on a list is not respected bellow .5em or .5rem. Could this be related?
Possibly related: when using relative units on the html tag, rem-based values defined elsewhere will have a lower bound of 9px.

See CodePen:

Workaround: absolute unit on html, em unit on body. rems everywhere else.

Sign in to add a comment