Scaling Fonts using em units

by Stephanie Rewis on February 5, 2008

As I train all over the world, one of the issues I try to spend a good deal of time on is helping people to understand the malleable em unit. And how to utilize it for good and not evil. :)

Anyone who knows me knows my burden for accessibility and the em unit is one of the most accessible ways to design. In fact, Greg and I spend a chapter on it in our upcoming book, so I won't go into a lot of detail here. But today, I stumbled upon a really great font-size calculator created by James Whittaker. If you'd rather keep it handy on your desktop, he also created it as an Adobe AIR application.

In reading the comments of his blog post, I saw a couple people questioning the reasoning behind decreasing the default text size of a user at all. And I began to answer those questions with my own opinions. About three paragraphs into my reply, it occurred to me that I was monopolizing James' comments and it was best done as a blog post of my own (please read James' post for the full story).

For the quick back story – the default text size of modern browsers is 16px (that would equal 1em). It's quite common to choose a 12px font-size which is 75% of the default sizing (.75em), as the base font size for elements on your page. (I'm not going to address here whether that should be placed on the body, or on individual elements.) The people responding in the comments were questioning whether we should adjust the base font size (something I've heard for years) since we're taking away “the experience the user expected.” My reasoning follows…

The Three Groups of Users

I likely don't have to remind you that back in the days of tag soup, 12px was a very common size to set type to on the web. In fact, even after many developers started controlling their typography with CSS, 12px was probably the most common size to set type to. So saying that people who leave their browser set to the default 16px size want that size is simply not true. They hardly know what it looks like since more often than not, it's overridden by other font sizing and styling anyway. And if they're like the average user, they don't have the inclination to change it either. They can see just fine, thank you. And they use most of their apps with the defaults they ship with (which explains why most of those same people use Internet Explorer — since it ships with their operating system). They're not upset that you changed their text size since they get what they have always seen and have come to expect.

Now, in the case of a low-vision user, this is not the case. If someone struggles with the issue of low vision and surfs the web regularly, they've probably developed a method of dealing with it. Users with aging eyes, many times instead of changing the base font size of their browser, have simply learned to use menus or key commands to bump the text size up. They change to a more comfortable size when necessary, but sometimes are limited by the fact that the site breaks in some way as they increase their font size. With this 75%/.75em font calculation, they get what they expect because they surf at default sizes to begin with and they still have control as well as a usable site at any size they settle on.

There are the more extreme vision-impaired that change their default browser text to 32px, 45px, or whatever size works for them. If they've changed their default to 32px, using the 75%/.75em size puts them at 24px. They can still use a key command to increase the text size if necessary. They're probably the users that know the most about making your site work for them because they need it the most. I'm guessing a great deal of the web is difficult for them to use (with columns that have one or two words per line, overlapping, elements getting cut off, etc). So though they don't get their initial optimum size (which is, most probably a common occurrence for them since many sites still use pixel sizing), they have the tools to increase the size a bit more if it's necessary.

Now, do not misunderstand me and think that I'm saying that since the very low vision user is the only one that doesn't get what they initially expect, that they're not important. They are and all users and user agents should have access to the content. I'm simply saying that the first two groups, and even part of the third (for the not uncommon pixel-based sites) see what they expect to see. And with em-based layouts, they have the tools to change them–very smoothly giving them a great experience. That's all.

{ 6 comments… read them below or add one }

Rod February 17, 2009 at 5:25 pm

Fonts, pt, px and em’s

Some notes on the subject

In your ‘Fonts equivalencies’ you really need to specify which browser is in use. Even then if designing you cannot rely on the ‘default’ font being 12pt, medium etc. It can be changed by the user. I have observed that Opera has a default of 13px but also inherits font size from other HTML and styles it is displaying. I use a css designed to equalize all my 8 browsers to 16px.

The font displayed must have a correction factor according to its ‘pt’ value. That is, if Arial font is 12pt (16px) in size on the screen then Times New Roman at 12pt is 92% of that and Super Black SF is 126% but still defined as 12pt. Even changing to 16px font size the point values are honoured.

I don’t have a MAC to confirm the 16px default but would doubt it as the pixel size of the MAC would now have to be 96dpi for correct page display of HTML documents. Or is it that the MAC browser is refomating the page as if it were a 12px font (72dpi). This would be a possibility as the Opera browser seems to be able to format all px values to em units so it can zoom everything correctly. Then how does the MAC handle the different size units (pt, px, em, ex and percent) and how does it know that a web page is formatted for a PC screen?

In your em-based div sizes example the results are what I would have expected.

My concern has been in achieving a standard format definition that works between browsers and secondly ensuring code generated is scaleable.

I would wish for more browser developement tools such as the

‘Developer:javescript console’ of Google Chrome and the ‘Advanced:Developer Tools’ offered by the Opera browser. Both of which relate the css properties to the code. Also a better code generator program that works in native ‘em’. I recently complained to one company because its code could not be zoomed even twice without loosing text or over flowing onto it’s non scaled images.

Perhaps more questions than answers still but the relationships are becoming clearer.

regards…Rod

David Hucklesby February 22, 2009 at 6:55 pm

You said: “all current browsers on both platforms now use 16px as their font-size default.”

Mostly true, but not entirely. My IBM laptop (1400 x 1050px on 15″ screen) runs at 120 DPI. While most browsers do indeed use 16px as the “medium” setting, IE (all versions) and Opera use 20px.

Other platforms may run at other than 96 DPI as well.

BTW – The link “view comments” does nothing for me. (Opera 9.63 on Mac.)

Stef. February 23, 2009 at 3:50 pm

Rod… Hi again. :)

As I said before, screen CSS should never use the pt unit. That said, it is equivalent to 16px FOR THE BROWSER DEFAULTS. Defaults are the way the browser ships of course, and yes, the user ABSOLUTELY can change that. Most won’t, but people with low vision (as well as web developers) may. That’s what started my first blog post on this subject about why I use the em unit for sizing my layouts as well as fonts. :)

I’m extremely unclear on what you’re saying about fonts needing a “correction factor” based on their point value. On the demo I linked to, you can see that fonts DO render at different sizes based on their font-family. This is why I always recommend checking the size of all fonts in the font cascade you create for elements on your page as you could get varying visual results dependent on what’s available on the user’s machine. You can’t set a different size for each font-family you define in your font cascade (yet!).

As far as the pixel size of the mac – yes, we’re now 96dpi just like PCs and apparently have for a while. :D

Opera has the same 16px default for both mac and pc. And they’re not actually translating it to em units to zoom (AFAIK), they’re simply magnifying the page. Just like IE7 will do by default if you increase the text size (though you can change that in your preferences so that only text zooms).

I think to sum it up, you’re thinking from a print perspective (you are originally a print designer?). You’re thinking that a pixel is an absolute size with an absolute measurement like a point. It is not. The literal pixel size will vary based on the resolution and set up of a person’s monitor but it will still relatively be the same size. (Meaning that all the 16px defaults will be the same size on each monitor — relative to each other.)

Does that make sense? (I’m going to create a little page to illustrate this shortly. I’ll let you know when it’s done.)

rod murgatroyd February 25, 2009 at 4:25 pm

Got your point Stef…pixels are still relative to a screen setup. My reading of the MAC px definition was that 1px = 1pt…NO not unless you are a printing man!!

Looking forward to your next page illustrating this.

…Rod

Michael Grosch February 26, 2009 at 7:19 pm

Thanks for turning the switch on thet lightbulb.

I also found this nice online tool that really helps converting px to em, which I wanted to share: http://pxtoem.com/

nexflo September 30, 2009 at 3:55 am

Automatic px to em resizing can be done at http://pxconverter.com/

allows file upload and on the fly conversion

Leave a Comment