Font sizing with rems

If rems are going to be used as the default font unit on a site, what would you say is the best way to set this up on the html and body elements?

Let’s say you’d like the body text across the site to look the equivalent of 14px, and you’d like to set this upfront so that only the exceptions to this font size (headings, asides, and so on) need to be specified further down in the CSS.

Would it better to start off like this…

html { font-size:100%;}
body { font-size:14px; font-size:0.875rem; } /* 14px/16px */

or like this…

html { font-size:62.5%;}
body { font-size:14px; font-size:1.4rem; }

I’ve read that it’s not advisable to change the default font size on the html element to anything other than 100% of what it is. But is that just for sites that go on to use ems, or does it apply to those going on to use rems as well? Some places (like snook.ca) are still alluding to the math-friendly 62.5% figure in their pieces on rems.

Would be interested to hear any views, suggestions or recommended best practices about this.

Did you mean “em”? What is “rem”?

[font=verdana]No, “rem” is a new unit that is introduced with CSS3 - see W3 specification – which means “font size relative to the size set in html {…}”.

As far as I can see, the only advantage of using rems instead of ems is that you don’t have to worry about nesting problems. So you can quite happily say div {font-size:0.9rem;} without worrying about divs within divs within divs having microscopic text. (But of course, you wouldn’t be setting your body text to anything other than 100% or 1em, would you, because you respect your visitors and you want to present your site at a size they find comfortable to read)

The whole “maths-friendly 62.5%” thing is a complete joke, and people who swear by it are usually (a) not very good at maths, and (b) stuck in a print-design world seeking pixel perfection, oblivious to the flexible requirements of web design. The idea of getting fonts to display at an exact size and facsimile rendering is totally antiquated, and with mobile phones and tablets becoming increasingly popular, the idea that you need text to appear at exactly 14px is a nonsense. So on that basis, I would never start by setting a base font as anything other than 100%, and I would never try to work out calculations to give an exact whole-number answer on the flawed premise of a set starting size. All you need to do is get the proportions roughly right and it will look just as good on just as many devices.[/font]

Hi Stevie

Well my initial intention was indeed to keep it 100% for precisely the reason you gave. The only reason I asked about 62.5% was because the few responsive sites using rems that I’ve seen all seem to be using it, which got me wondering whether I was perhaps missing something about how rems worked with a user’s default font size.

But just to be clear, can I take it from your answer that you think this…

[INDENT][COLOR="#0000FF"]html { font-size:100%;}[/COLOR]
[COLOR="#0000FF"]body { font-size:14px; font-size:0.875rem; }[/COLOR][/INDENT]

…would be an okay way to start things off?

[font=verdana]I’m not keen on changing the size of body text from 100% by any method. There are a number of issues I have with that code:

  1. Using rems on <body> is a waste of bytes, you might as well just as ems and save the hassle of worrying about catering for IE≤8. As I said, the reason for using rems is to avoid worrying about nesting problems. As you can only ever have one <body> tag, you’re not going to get nesting problems, so you gain nothing.

  2. Setting a pixel size for IE≤8 is an accessibility/usability problem, because it means that people who have set their default text size to be larger have that decision overridden and get lumbered with text they find illegibly small. (And that assumes they aren’t still stuck with IE6, in which case they won’t even be able to zoom). If you’re going to tell people that they have to read a website in a font smaller than the one they want to, at least use ems/% so that it scales down the same proportion for everyone!

  3. What’s the point of setting a size of 100% on <html>? It doesn’t do anything! You might as well leave that bit out.[/font]

Why? The common browser default size (16) can still look uncomfortably big for the majority of users. By specifying a smaller font size on the <body> element (not the <html> element), all we’re doing is establishing this smaller size as a kind of catch-all; the most common size text used across the site. This seems to me an entirely legitimate and efficient way to work, as all we then need to do is override it for our headings, aside paragraphs, and so on. If we didn’t set this font size on <body>, we’d only do it somewhere else (possibly in several places and using up more bytes).

On your 3 points…

That’s a good point and one that I missed.

I assume what you’re talking about here is still specifically in relation to not using px/rem on <body> - is that right? (If you’re talking about the use of rems with pixel fallbacks more generally, I can say that on the majority of sites I work on, I would not be using rems at all. It’s only on the current site where I’m afforded that ‘luxury’ :wink: )

I include it here because:

a) most CSS resets have font size % specified on <html> (usually alongside other elements).
b) I vaguely recall it fixing some browser bug or other (can’t remb which, but different to one that recommends a 100.01% fix).

No, the older versions of IE don’t let the user make text bigger if it’s set in px—meaning that even if they want bigger text, they can’t have it.

I vaguely recall it fixing some browser bug or other (can’t remb which, but different to one that recommends a 100.01% fix).

That was an old trick for the body font size for a long dead browser (an old version of Opera).

There’s no purpose that I’m aware of for setting font size on the <html> element. The norm is to set a font size on the <body> … though it’s not really necessary now.

I always set the body font size at 100%, just for the heck of it (which is small for some fonts) but I know others prefer something like 85%. Anything smaller than that is not very nice for users. I usually bump up fonts even when they are set to 100%, because I like large print … even though I don’t have sight issues. I hate sites with small font sizes, even if I can read them. They seem stingy to me, and you know the designer cares more about the design than the visitor trying to access the content.

[quote=“ralph_m,post:7,topic:19250”]

No, the older versions of IE don’t let the user make text bigger if it’s set in px—meaning that even if they want bigger text, they can’t have it.[/QUOTE]
Thanks Ralph but I’m aware of that. I was asking whether Stevie’s second point was intended as an objection to rem-with-px-fallback being used on the <body> tag, or whether it was intended as an objection to their use more generally - i.e., not to use rems until the proportion of IE8 users is sufficiently small as to justify it because the px fallback they receive is less accessible/usable. If the latter, then it’s not an issue for my current site because the proportion of IE≤8 uses is minuscule.

Ah, I did wonder. I tend to start off with resets that include font size 100% in the same style declaration as body, div, span, etc (à la Meyer). I notice Normalize.css includes it more-or-less by itself.

Like Sitepoint you mean? :smiley:

Yeah, SitePoint’s default font size is absolutely ridiculous for big monitors on high resolutions. I’m on a big monitor with a high res and, boy, I need to “up” the font-size by 300% to make it readable!

[font=verdana]

Nuh-uh. As I said, I disagree in principle with changing the font size of body text from the user’s default. Of course, to an extent it depends what font you’re using. With fonts that “appear larger” such as Verdana and Georgia, it won’t hurt as much to scale them down a bit, but more compact fonts such as Calibri and Arial really shouldn’t be shrunk any further.

I realise I may be being naive in expecting users to set their default text size to the size that they want text to be by default, but it seems unreasonable to penalise those people who have done so by giving them a design where the text is smaller than they want.

I assume what you’re talking about here is still specifically in relation to not using px/rem on <body> - is that right? (If you’re talking about the use of rems with pixel fallbacks more generally, I can say that on the majority of sites I work on, I would not be using rems at all. It’s only on the current site where I’m afforded that ‘luxury’ :wink: )

I’m talking about using px (whether as a fallback for rems or otherwise). Remember that some people may have their default font size set not just a little bit bigger than you expect, but much bigger (32px is not unheard of!). If you insist on sending people text smaller than their default, and you set it at 85%, then those people who need mahoosive text will still get it at 27px, which may still be just about big enough, whereas if you set it at 14px then they’ll get it at 14px and will be barely able to see there’s any text there.

So…

that’s pretty much it. Because if you’re using rems as the preferred method, it’s probably going to be a lot of work to re-code all those font sizes into ems for IE≤8, and having to do so would render the time-saving of using rems unnecessary because you’ve had to do the work anyway. So until IE≤8 has negligible usage (and I don’t know how well supported it is on mobile browsers) such that you can ignore the usability problems of having px as a fallback, it isn’t suitable for real-world deployment. As my main site currently has 16% of visitors using IE≤8, that’s about 16 times too many for me to consider it viable.

Like Sitepoint you mean? :smiley:

We don’t always agree with the code and design of Sitepoint![/font]

It’s also used to fix the scaling bug in IE7 and under. If you don’t set the body using percent then any em sizes used on other elements will be much larger than they should be when the text is resized via the browser. That’s why percent was incorporated into resets to counter this bug.

That rings a bell, thanks Paul.

And thanks also to you Stevie for coming back and clarifying.