Setting font size (em's)?

Setting font size ?

Hi all

If I’m using em’s to set the size of my fonts the font size will be a percentage of the base font size set in the browser. So if the font size is set to 12px then 1em will be 12px and 2em will be 24px - Is this correct ?

If this is correct should I always set the base fonts size myself in css :


body {
  font-family: Helvetica, Arial, sans-serif;
  font-size: 16px; /* Scale origin */
}

Essentially, though remember that users can set their own base font sizes that will override yours. Also, font sizes are inherited, so if your base font size is 16px, and if you have the font size on a particular div set to 1.5em, and a <p> inside that div set to 1em, the <p> would be 24px in size.

It’s considered a better practice to set the base font size in % rather than pixels, though. Pixel sizes for fonts are not very user-friendly.

Ralph is right. But I would recommend you think about ems differently.

As you mentioned in your OP, if you set the base in pixels (12px, for example) any direct descendant of the base element(body) with a font-size of 1em will be 12px, if it was 2em it would be 24px … and so forth. Some experience members of the forum will advise against setting a base font in px, tho I personally can see its usefulness. As was suggested you may set the base font in %, this will base the root element on the UA’s default font size, which varies from browser to browser and user to user… ugh.

it’s important to note that if you set your font-size:2em and then a child element is set to 2em as well the actual size for the font with relation to the base font will be 4em (48px)…
for this reason setting font size in ems is EQUIVALENT to setting font size in %.

the true power of the em scale is to set sizes, paddings, margins, positioning, etc.

For example .element{ font-size:150%; padding:1em ; width:55em; margin-top:2.5em}

this will make a container and breathing space of your element proportional to your elements calculated font size.

NO!!! NONONONO!!!

If you set it to 16px on body, every element on the page will inherit from that 16px DEFEATING THE ENTIRE POINT of using %/EM in the first place! That point being not all browsers and screens start with the same default size. Specifying PX on body OVERRIDES that! You might as well at that point declare the entire page in PX – which is pretty much what saying that on body does!

My computer for example is set for large fonts/120dpi, so my default size is 20px and I expect all %/em to be scaled off that 20px. You set 16px you’re basically feeding me “absurdly undersized fixed metric fonts” across your entire page – even if you use %/EM everywhere else in the CSS! %/EM is based on the parent element, so if you set the topmost parent of the page to PX – FAIL HARD.

The whole point of %/EM is for fonts to auto-adjust to the device and/or user’s defaults or preferences, something PX inherently overrides. Declaring PX on body fairly well bends over the table any chance of %/em being useful on the page in that department.

Thanks for the correction, ds. I’ve always been a bit vague on that. Didn’t think px on body could override the user’s preferences, but glad to know for sure. I’ve never used px on <body>, so have never tested this in practice.

It’s the thing about %/em most people actually miss – inheritance and the cascading part of CSS. %/EM when it comes to fonts always means a percentage of or based on the current size… the current size 99% of the time inherited from the parent element.

Since all tags on the page have BODY as their parent element, they all tend to inherit off body with TWO major exceptions.

  1. form elements. This one can really drive you buggy but form elements by default start out at the system default instead of inheriting from body or the immediate parent… though if you set them to font-size:100% explicitly, they behave normally.

  2. tables in IE5 and/or quirks mode IE (standards mode IE behaves like RoW on that). If you’re not aware of this one and find yourself forced to support those browsers, it can drive you even battier than the first example. It’s why some resets explicitly state “table { font-size:100%; }” so that older browsers or jhvh help you things end up in quirks mode, the table still inherits. I don’t use tables often enough anymore to keep that in my reset, and when I do use a table I just keep that in mind.

His entire first relationship is correct… if you start at 16, declare 50% you get 8… declare 50% inside that you get 4…

But that’s WHY it should be used – what browsers start at can vary. A good many users used the 120dpi setting, Win7 has the option to set up to 360dpi for when/if that level of dot pitch display becomes available; on the whole Windows has been light-years ahead of the competition on that front anyhow since I’ve been running large fonts/120dpi all the way back to when it was introduced for the 8514 graphics adapter on windows 3.0. Back then it wasn’t even about making the fonts bigger, but running one resolution notch higher getting more dots per inch – the only way to cut down on jaggies until font smoothing came along… some true *nix boxes (sorry, linux and OSX don’t count on that front) give you the choices of 75dpi or 100dpi (under the hood X11R6 which x.org is based on is hardwired for those), some handheld use a 72dpi setting, making their default size 12px… as mentioned 120dpi is 20px, the 144dpi I’m using on my media center PC ends up 24px. (36" 1920x1080 is illegible at 96dpi when you’re more than six feet away – like say on my couch)

It ends up a bit like the question “what width/resolution should I be targeting” – if you’re even asking the question, you haven’t quite grasped the point of HTML/CSS… or the multitude of devices and screen sizes your page might end up being shown on.

Again why I laugh and call most px font websites “absurdly illegibly undersized” and fixed width layouts “pathetic” – and am really starting to like media queries combined with mcSwitchy scripting assists.

So just to be clear: does setting fonts to 12px on the <body> element override any font settings on a user’s machine? All the dpi stuff makes my eyes spin a bit.

Yes… with two exceptions:

  1. Form elements in all browsers (INPUT,TEXTAREA, etc) if you don’t specify %/EM on them.

  2. Quirks mode IE tables…

The DPI thing isn’t that confusing. The defaults for the four most common sizes are:

72-75dpi – legacy *nix and some handhelds == 12px

96 dpi – normal users (windows ‘small’) == 16px

120dpi – windows ‘large’/win7 ‘medium’ == 20px

144dpi – win7 ‘large’ == 24px

Which is why %/em should be used, so that users with a different “system metric” get their default font size instead of having it overridden to a size that’s too big or way way way too small.

In the handful of cases where you are FORCED to use px due to something like an image interaction or 100% min-height layout, 12px should be considered the smallest acceptable size, and I get “twitchy” below 14px on most fonts; though for serif fonts you want to bump those numbers 20-25% or so due to the more complex glyphs causing legibility issues.

I always make everything relative to 1em and go from there.

Thanks DS. Very useful info. :slight_smile: