Chrome not respecting rem font size on body tag?
Asked Answered
P

8

14

I've taken to using rem's to size fonts in recent projects, then using px as a fallback for older versions of IE.

I've also been setting a font-size of 62.5% on thehtml so I can more easily set font sizes later on in the stylesheet, I then set a font-size of 1.4rem on the body so unstyled elements have a base font-size of at least 14 pixels, see the code below:

html { font-size: 62.5%; } /* font-size: 62.5% now means that 1.0 rem = 10px */
body { background: #fff; font-family: arial; font-size: 1.4rem; line-height: 1.6rem; }

The problem is, Chrome seems to handle this in a strange way ... Chrome seems to set the font sizes correctly on the inital page load, but on subsequent refreshes the font sizes are way bigger than they should be.

SEE FIDDLE (HTML copied below for future reference)

<!DOCTYPE html>
<html lang="en-GB">
    <head>
        <title>Page Title</title>
    </head>
    <body>
        <p>This is a test, this font should have font-size of 14px.</p> 
        <p>This is a test, this font should have font-size of 14px.</p> 
        <p>This is a test, this font should have font-size of 14px.</p> 
    </body>
</html>

Remember, you might need to hit run once or twice in Chrome to see said effect.

Does anybody know what is causing this or if there's a way around it? Am I committing a crime by setting a 62.5% font-size on the html element (I realise there are arguements against doing so)?

Plainspoken answered 20/11, 2013 at 15:20 Comment(18)
"Am I committing a crime by setting a 62.5% font-size on the html element (I realise there are arguements against doing so)?" No, you're not. It should be 62.5% of the user-set default font size, which as you know is typically 62.5% of 16px = 10px.Letterpress
I've tried and tried and tried but I cant repeat your issue :(Froufrou
@ExtPro I'm pretty sure it's not restricted to my install of Chrome (just had a colleague replicate the issue) try viewing: jsfiddle.net/HfwSm/embedded/result in Chrome and refreshing the page a couple of times after it finishes loading.Plainspoken
FWIW, I was able to reproduce this with the steps described in the question.Letterpress
@Letterpress thanks - don't suppose you've got any ideas what could be causing this / how to fix?Plainspoken
Not in the slightest :/Letterpress
Might be semantics- I see the size jump, my assumption was the font size was staying at the larger size?Froufrou
It seems that Chrome is ignoring the font-size & line-height set on the body during subsequent refreshes, although I don't know why ... setting the font-size on the p itself (using 1.4rem) gets the desired results, but I don't want to have to set the font-size + line-height in this way for everything.Plainspoken
@ExtPro I don't think it's a semantics issue, I think this is tied to the CSS in some wayPlainspoken
@Plainspoken Dunwoody, I meant semantics as in I understood something different from reading the question :)Froufrou
@ExtPro ah ok, that makes more sense! Sorry if the question isn't immediately clear, might go back and edit it a bit later.Plainspoken
"Am I committing a crime by setting a 62.5% font-size on the html element" No, the crime is that you're setting the font-size to 62.5% period. see: csswizardry.com/2011/05/font-sizing-with-rem-could-be-avoided and filamentgroup.com/lab/…Bodyguard
If you load it with the incorrect font size, inspect the p elements, then uncheck and check the font-size: 62.5% it fixes itself.Letterpress
@Letterpress I'd noticed that messing with developer tools seems to fix it sometimes too ... maybe a weird Chrome bug of some sort?Plainspoken
@Bodyguard I've read both articles before and disagree with both of them (for the most part), if my code above worked properly in Chrome then the whole "you have to style every single element that falls under ‘body copy’ individually." is no longer valid. I also find it strange that someone would find font-size: 1.714rem; easier to maintain, even if it means marginally less font sizes are defined in your stylesheet.Plainspoken
I wouldn't rule that out. Chrome has all kinds of rendering quirks, almost makes it IE-like.Letterpress
Have been debugging the exact same issue. For those able to recreate, what version of chrome? I'm seeing it on Version 31.0.1650.57.Secor
Another documented case: surefirewebservices.com/development/genesis-framework/…Secor
F
9

Try:

html { font-size: 62.5%; } /* font-size: 62.5% now means that 1.0 rem = 10px */
*{font-size: 1.4rem;line-height: 1.6rem; }
body { background: #fff; font-family: arial;  }

Seems to look better on refreshing the page :)

FIDDLE

Froufrou answered 20/11, 2013 at 15:52 Comment(3)
This works, but I'm reluctant to use the * selector as I've heard it's quite inefficient, it also means I'll have to set font-sizes for h1, h2 etc.Plainspoken
Not at all- and regarding efficiency, have a read here: calendar.perfplanet.com/2011/… and the 'performance' section here: paulirish.com/2012/box-sizing-border-box-ftwFroufrou
should be em instead of rem wp-code.com/wordpress-snippets/…Cedell
O
22

The easiest solution that I have found is to simply change the body definition to

body {
    font-size: 1.4em;
}

Because it is the body, you don't have to worry about compounding – just use rems everywhere else.

Offensive answered 26/11, 2013 at 1:10 Comment(1)
This seems to be the best fallback solution to me.Pero
F
9

Try:

html { font-size: 62.5%; } /* font-size: 62.5% now means that 1.0 rem = 10px */
*{font-size: 1.4rem;line-height: 1.6rem; }
body { background: #fff; font-family: arial;  }

Seems to look better on refreshing the page :)

FIDDLE

Froufrou answered 20/11, 2013 at 15:52 Comment(3)
This works, but I'm reluctant to use the * selector as I've heard it's quite inefficient, it also means I'll have to set font-sizes for h1, h2 etc.Plainspoken
Not at all- and regarding efficiency, have a read here: calendar.perfplanet.com/2011/… and the 'performance' section here: paulirish.com/2012/box-sizing-border-box-ftwFroufrou
should be em instead of rem wp-code.com/wordpress-snippets/…Cedell
H
4

The * selector is very slow, as the author of this bug in Chrome, I'd advise a workaround like this until the bug is fixed:

body > div {
    font-size: 1.4rem;
}

Provided you always have a wrapper div anyway ;)

Housewarming answered 24/11, 2013 at 11:31 Comment(2)
Works really well for everything but padding/margins unfortunately (and widths too presumably, although I haven't checked them yet!).Plainspoken
This worked a lot better for me. The * selector is to agressive making things, well, complicated.Curtate
R
4

Yes, this is a known bug in Chrome, which has been linked already.

I found

html { font-size: 100%; }

seems to work for me.

Rawboned answered 22/12, 2013 at 0:51 Comment(1)
Yes, this works. Proceed like in this commentTindall
F
3

This seems to be a Chrome bug; see Issue 319623: Rendering issue when using % + REMs in CSS, and/or a partly-merged duplicate: Issue 320754: font-size does not inherit if html has a font-size in percentage, and body in rem

Follett answered 24/11, 2013 at 19:13 Comment(1)
Seven years later this bug still exists.Tindall
J
2

The answer of Patrick is right. We have the same issue on Android 4.4.3 WebView.

Before:

html {
    font-size: 62.5%;
}

body {
    font-size: 1.6rem;
}

After:

html {
    font-size: 62.5%;
}

body {
    font-size: 1.6em;
}

With em and not rem, it works !

Jaclyn answered 6/6, 2014 at 16:35 Comment(0)
P
0

The way I fix this is by setting an absolute font-size in the body-element. For all the other font-sizes I use rem:

html {
    font-size: 62.5%;
}

body {
    font-size: 14px;
}

.arbitrary-class {
    font-size: 1.6rem; /* Renders at 16px */
}
Pteridology answered 27/5, 2014 at 9:4 Comment(1)
Using pixels will ignore a userconfigured font size in Chromium based browsers (not in Firefox).Tindall
B
0

try to use display: flex; inside the text block div or span

Broad answered 24/4 at 21:38 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.