A List Apart

 HOME

 ARTICLES

 EVENTS

 TOPICS

 WRITE FOR US


How to Size Text in
CSS
by Richard Rutter November 20, 2007Published
in Browsers, CSS, HTML, Layout & Grids, Typography & Web

Fonts
There’s been a welcome resurgence
of interest in web typography over the
past year or so, with
many articles and conference talks off
ering techniques and theory.
Frequently asserted is the notion that
good typography requires accurate
control of font size and line-height.
But this is the web: it’s a special
medium where the reader can have as
much control as the designer—the
implication being that text on the web,
while bending to the designer’s will,
must also be reliably resizable across
browsers and platforms.
96 comments
Share this on



 A Book Apart:
Brief books for people who make websites.

An Event Apart:
3 days of design, code, and content for web & UX designers &
devs.

In this article, we
will reconcile the
designer’s
requirement for
accuracy with the
user’s need to
resize text on
demand, arriving
at a best practice
that satisfies
designers anduse
rs and works
across browsers
and platforms.
We’ll reach our
destination by the
traditional
method of trial
and error. With
more than a nod
to Owen
Briggs’s pioneerin
g work of 2002, I
have created a
base case with six
iterations and 161
screenshots.
Follow along,
won’t you?

The test
suite
The content used
for testing
purposes was a
two-column
layout with body
copy on the left
and a sidebar on
the right. Text
was set in Arial to
aid consistency
across operating
systems and
platforms.
The browsers
used for testing
were Safari 2,
Firefox 2 and
Opera 9.5α
running on
Mac OS X Tiger,
along with
Internet Explorer
6 (IE6) and
Internet Explorer
7 (IE7) running
on Windows XP
with ClearType
turned on. Clearly
this is not an
exhaustive list of
browsers,
operating
systems, or
rendering
engines, but it
covers the
majority of users
out there today.
Each operating
system and
browser was run
using its default
settings. Every
iteration was
tested to see how
each browser
rendered text at
smaller, medium,
larger, and largest
sizes, along with
90%, 100%,
110%, and 120%
page zoom levels,
where applicable.

Base case
First it was
necessary to
verify that
browsers
provided a
consistent
baseline from
which to start.
The base
case shows that in
each browser, the
default text size is
consistently 16px
when no styles
are applied (other
than the browser
defaults), and the
text scales fairly
consistently
across the board.

Text size in
pixels –
iteration 1
The default text
size of the base
case is a good
starting point,
but for most
people
(designers,
clients, and their
customers) 16px
is too large for
body text. In our
example, the
body text was
reduced to 14px,
with the sidebar
set at 12px. This
first iteration
does just that,
setting the fonts
in pixels:

.bodytext p {

font-
size:14px;

}.sidenote {

font-
size:12px;

}
The result is that
Safari and Firefox
still resize the
text,
whereas IE6 and
IE7 do not. The
text can be
resized in Opera
and IE7 by using
the page zoom
tool, which
magnifies the
page layout, text
and images
within.

Text size in
ems –
iteration 2
Although browser
market share
differs from site
to site, and
browser share
statistics are
drawn in sand,
it’s safe to say
that IE6 is still
used by many
people. So setting
text in pixels
would leave many
people no means
of resizing it.
There’s also an
argument that
says IE7 users
should be able to
resize text
without being
forced to use the
zoom control.
The next unit to
try for text sizing
is ems. The em is
a true
typographic
unit, recommend
ed by the W3C,
and affords a
precision keywor
ds lack. Working
from a default of
16px, the
following styles
should give the
desired text sizes:
.bodytext p {

font-
size:0.875em;
/* 16x.875=14
*/

}.sidenote {
 font-
size:0.75em;
/* 16x0.75=12
*/

The results show

that, across all
browsers, text at
the medium
browser setting is
rendered
identically to text
set in pixels. It
also
demonstrates
that text sized in
ems can be
resized across all
browsers.
However IE6 and
IE7 unacceptably
exaggerate the
smallness and
largeness of the
resized text.

Body sized
as
percentage
– iteration 3
A fix to the
exaggerated text
resizing
of IE6 and IE7 is
to size the body
using a
percentage. So
retaining the ems
on our content,
the following
styles were
tested:
body {

font-
size:100%;

}.bodytext p
{

font-
size:0.875em;

}.sidenote {

font-
size:0.75em;

}
The results show
that the
difference
between larger
and smaller
browser settings
in IE6and IE7 is
now less
pronounced,
meaning we now
have all browsers
rendering text at
an identical size
on their medium
setting, and
resizing text
consistently.

Setting line
height in
pixels –
iteration 4
Recent web
typography
articles such as
“Setting Type on
the Web to a
Baseline Grid” (A
List Apart, April
2007) stress that
good typography
requires a vertical
grid, that is to say
a solid vertical
rhythm achieved
with a consistent,
measured line-
height. The key
implication is
that line-height
should be the
same regardless
of the size of the
text (so that line-
height, or the
vertical grid,
remains
consistent,
regardless of font
size).
For our example,
a suitable line-
height is 18px, so
that is added to
the body as
follows:

body {

font-
size:100%;

line-
height:18px;
}.bodytext p
{

font-
size:0.875em;

}.sidenote {

font-
size:0.75em;

The results show

that the 18px
line-height is
inherited by all
text on the page—
note how the
sidebar text has
the same regular
rhythm as the
body
copy. Specifying
a unit (in this
case, px) when
setting the line-
height enables
the value to be
inherited
throughout the
page. If a unitless
line-height had
been specified,
the multiplier w
ould have been
inherited,
resulting in line-
heights being
rendered
proportionally to
the text size, thus
breaking the
vertical rhythm.
Unfortunately the
results show that
the 18px line-
height is not
scaled
by IE6 and IE7wh
en text is resized,
meaning the
largest setting
appears to squash
the text.

Setting line
height in
ems –
iteration 5
When pixels
failed before, we
turned to ems.
Repeating the
logic gives us the
following styles:

body {

font-
size:100%;

line-
height:1.125e
m; /*
16×1.125=18
*/

}.bodytext p
{

font-
size:0.875em;

}.sidenote {

font-
size:0.75em;

The results show

accurate,
consistently
resized text and
line-height across
all browsers.
Perfect. Or nearly
so.

The Safari
monospace
problem –
iteration 6
The observant
among you may
have noticed a
wee glitch in the
Safari screenshot
s: the
monospaced font
included in the
body text is
rendered
inconsistently.
For text set in
pixels, Safari
renders the
monospaced font
at the same size
as the
proportional-
width text
surrounding it.
When text is set
in ems, however,
Safari renders
monospace text
much smaller
than the
surrounding text.
The inconsistency
appears to stem
from Safari’s
default text sizes,
which are 16px
for “standard
fonts” and 13px
for “fixed-width
fonts.” Safari 3α
on OS X does not
appear to suffer
from this
problem.
You could decide
that undersized
monospace text
in Safari is
something you
and your readers
can live with, and
as Safari 3 is
included in OS
X Leopard and
the latest update
to Tiger, it will
not be long until
the problem
pretty much
disappears. For
the nervous
control freak who
can’t wait, an
alternative fix is
to send text sized
in pixels to Safari.
The following
code appends
a downlevel-
revealed
conditional
comment to our
styles, so that
pixels are sent to
all browsers
except IE6 and IE
7 (note the [if
!IE] syntax,
instructing
IE/Win to ignore
the markup that
follows).
<style
type="text/cs
s">

body {

font-
size:100%;

line-
height:1.125e
m;
}.bodytext p
{

font-
size:0.875em;

}.sidenote {

font-
size:0.75em;

</style><!--
[if !IE]>--
><style
type="text/cs
s">

body {

font-
size:16px;

</style><!--
<[endif]-->

The results show

consistently
resized text and
line-height across
all browsers,
including the
monospaced text
in Safari 2.
Conditional
comments are
controversial,
with
many detractors a
nd proponents,
but I believe the
approach is
appropriate in
this case, as we
are using a
browser feature
(conditional
comments) to
work around a
browser
behaviour (non-
resizing of
pixels). It should
also be noted
that, for the sake
of clarity, the
code listed above
presents CSSrules
within style elem
ents; best practice
would dictate the
use of linked style
sheetsinstead.
Conclusion
Our task was to
find a way to size
text that allows
designers to
retain accurate
control of
typography,
without
sacrificing the
user’s ability to
adjust his or her
reading
environment. We
tested various
units across
common
browsers. Sizing
text and line-
height in ems,
with a percentage
specified on the
body (and an
optional caveat
for Safari 2), was
shown to provide
accurate,
resizable text
across all
browsers in
common use
today. This is a
technique you
can put in your
 kit bag and use as
a best practice for
sizing text
in CSS that
satisfies both
designers and
readers.
ADDENDUM
Ems can be tricky
to work with,
especially when
nesting elements
deeply, as it can
be hard to keep
track of the
maths. However,
commenting your
style sheets well
and styling
elements from
the body inwards
can keep things
easier to follow.
This
more complex
example and
its accompanying
style
sheet demonstrat
e how to size
nested elements
using the body as
the starting point.
Also in Issue № 249
Understanding Web Design
We’ll have better web design when we stop asking
it to be something it’s not, and start appreciating it
for what it is. It’s not…
Further reading aboutCode
Responsive Comping: Obtaining Signoff without Mockups
If you’re making websites, chances are you’ve given some thought
to what constitutes a responsive-friendly design…

Mo’ Pixels Mo’ Problems

Mobile devices are shipping with higher and higher PPI, and
desktops and laptops are following the trend as well. There’s no…

About the
Author

Richard Rutter
Richard Rutter is a co-founder and user experience consultant
at Clearleft, a strategic design studio based in Brighton, UK.
Richard has been solving clients’ problems through digital design
for over two decades, but is probably best known as a self-
appointed web typography evangelist. In 2017 he published his
long-awaited book, Web Typography. Richard occasionally blogs
on a site called Clagnut and can be found @clagnut.

MORE FROM THIS AUTHOR

  Web Typography: Designing Tables to be
Read, Not Looked At
 Web Typography: Numerals

ALSO FROM THIS AUTHOR

Web Typography by Richard Rutter
This book is a practical guide and companion reference to all
aspects of typography on the web. It deftly combines implement-
ation details with typographic theory, and is ideal for designers,
developers and anyone else involved in the process of creating a
website.
➝ Buy nowGet our latest articles in your
inbox. Sign up for email alerts.

96 Reader Comments

1.

Kari Pätilä 3:26 pm on November 20, 2007

Aren’t the problems with em sizes on IE6 and IE7 caused by the
fact that an em is a bit smaller on those browsers? .9759 times the
size of a “regular” measure, if I’m not mistaken.
 EMBED

2.

Ben Sekulowicz 4:15 pm on November 20, 2007

I’ve always followed the 62.5% method - setting your body to have
a font size of 62.5% means that any browser where the user hasn’t
deliberately* changed their default font settings will set 1em equal
to 10px. This means subsequent calculations are much easier and
you can increase/decrease not only your text sizes but your entire
grid, depending on how large/small the text is.
For an example, see the top few rules of “this CSS
file”:http://www.beseku.com/includes/css/screen/core.css to see
font sizes being easily calculated.

EMBED

3.

Ben Sekulowicz 4:16 pm on November 20, 2007

* Sorry, the asterisk above was because if a user has set their font-
size to be something different, I don’t want to be ‘that guy’ - the
one who changes it, (see also, resizing browser windows).
 EMBED

4.

David Leader 4:34 pm on November 20, 2007

For those that want to use constant line height, your article will be
useful; and those that don’t can ignore that part of it. However,
although you cite others for regarding this as good typography , I
gather that you embrace the concept yourself. This certainly isn’t
the accepted wisdom for print, and it is ironic that the ALA page
on which your article appears doesn’t go along with this either. I
don’t accept every aspect of the ALA style (block paragraphs are
my own special hate), but the smaller leading for items in the
sidebars just seems to work. The converse I do not find to be true.
I’m all for grids and rhythm on a page, but I think fixed leading
irrespective of type size is out of tune.

EMBED

5.

James Smith 5:16 pm on November 20, 2007

I’d like to echo Ben’s comment above; the 62.5% method is surely
one of the most widely used em-sizing techniques but doesn’t get
any coverage in this article.
 Personally I set my font-size:62.5% on the <html> element,
leaving my <body> free to set a sensible em size to cascade down.

EMBED

6.

Adam Weis 5:48 pm on November 20, 2007

Wouldn’t this then cause anyone with a different browser
default(I use 14px) to be shown text that is clearly not the same
size as the designer intended them to see? If you apply the 62.5%
method to my browser, you would then be presenting me with
8px text.
Should you really force some of your users to resize the text
before they can read anything on your site?

EMBED

7.

Douglas Neiner 5:53 pm on November 20, 2007

I too have been using the 62.5% method ever since I picked it up
from some “WordPress”:http://www.wordpress.com themes I
was looking at. It has worked well for me, but I am going to try
this method in my newest site I am about to start work on. I really
 appreciate the time the author took to make screen shots to show
the comparisons.
Now… if only our clients understood how hard it is to get the fonts
sizes consistent in all browsers… :)

EMBED

8.

paul irish 6:14 pm on November 20, 2007

I’m pissed as anyone else that you did not mention the 62.5%
rule. I was like.. ‘who is this amateur?’. But then I see the link to
Clagnut. “You are the person the internet has to thank for the
62.5% rule!”:http://clagnut.com/blog/348/ ! Well thank you.
I would, however, like to have seen some review of the techniques
that CSS frameworks like YUI, Blueprint, and Tripoli use.

EMBED

9.

paul irish 6:16 pm on November 20, 2007

“http://clagnut.com/blog/348/”:http://clagnut.com/blog/348/
 EMBED

10.

Jeffrey Zeldman 6:50 pm on November 20, 2007

Thanks, @Paul Irish. Exactly.
Mr Rutter is the author who introduced the 62.5% rule many of us
are already using. And now he is introducing a new best practice,
based on experimentation shown in the article, and a desire to
control the vertical grid as well as the font size.
Perhaps readers will forgive this innovator for continuing to
innovate on our behalf, and will now actually consider what he
has to say in the article, instead of criticizing him for not sticking
with the rule he himself gave us.

EMBED

11.

Cameron Yule 7:08 pm on November 20, 2007

A good, robust way of writing cross browser font-size CSS is
something “we’ve”:http://www.tictocfamily.com/ been discussing
at work recently.
 We had previously been using the 62.5% technique and were
fairly happy with it until reading about the associated issues with
users who had changed the default text-size of their browser
(incidentally, it was while exploring the rather useful
“Blueprint”:http://code.google.com/p/blueprintcss/ framework
that I read this).
One of the team here had suggested using pixel sizes for all but
IE6, which would be given it’s own, percentage-based, styles but
that just seemed like too much work for my liking (maintenance
would also be made more difficult).
As much as using em’s can be a pain while dealing with nested
elements, at least we now have a proven solution that would
appear to cover all bases.
Thanks to the author for sharing. :)

EMBED

12.

Jeffrey Zeldman 7:14 pm on November 20, 2007

@Cameron: Using pixel sizes for all but IE6 is something we’ve
done at Happy Cog more than once (see Daniel Mall
“here”:http://www.danielmall.com/archives/2007/02/07/the_ag
ency_formerly_and_currently_known_as_happy_cog.php for
instance).

EMBED
13.

derek allard 7:48 pm on November 20, 2007

I’ve been using the keyword method advocated by Dan Cederholm
in Bulletproof Web Design where you set the font size with a
keyword and then adjust by percentages off of the keyword. Has
worked very well for me and was curious why no mention of it
here.

EMBED

14.

Wilson Miner 8:04 pm on November 20, 2007

I think the combination of techniques here is brilliant, and will
make a great foundation for universal typesetting best practices
on the Web. I still can’t help thinking that it’s a ridiculous state of
things that one browser dictates so much complexity (however
elegantly executed) to achieve such a basic technique. But if we
worked around the box model for this long, I think we can handle
this until IE6 goes to that single-digit percentile in the sky.

EMBED
15.

Brad Kemper 8:26 pm on November 20, 2007

Another article about how to work around IE’s shortcomings.
Every other browser on Earth can enlarge or reduce text that is
set in pixels. I will continue to specify my fonts in pixels, and if
anyone wants to resize it, then they can zoom the whole page or
download a more capable browser. Most of the people who are
still using IE are the same sort of people who will never even click
on their menu bar to see that there are text resizing controls, so it
is a waste of my time to use complicated workarounds to
accommodate the small minority who expect to resize text in IE.
It is Microsoft’s choice to not let my text be resizable, not mine. If
people accept IE as their browser, then they are accepting that
decision and should live with it.
On the issue of “vertical rhythm” as being good typography: its a
bunch of BS. Somebody made that up a year or so ago, but it is
certainly not accepted as good typography. In fact, the space
between paragraphs should be less than a full line, as that IS
accepted as good typography.

EMBED

16.

Brad Kemper 8:27 pm on November 20, 2007

 “Math’ is non-countable. There is no plural of “math”.

EMBED

17.

Meryl K. Evans 8:32 pm on November 20, 2007

@Brad Kemper: The idea of vertical rhythm is much older than
one year. Where is it said that paragraphs should have less than a
full line between them?

EMBED

18.

Jody Ferry 9:11 pm on November 20, 2007

@Brad Kemper: Jason is right, vertical rhythm is as old as
dirt. To reiterate, the author’s goal here is to “reconcile the
designer’s requirement for accuracy with the user’s need to resize
text on demand, arriving at a best practice that satisfies designers
and users.”

EMBED
19.

Philip Hutchison 9:14 pm on November 20, 2007

I’d like to thank you for putting so much time and effort into this
article. The screenshots were especially useful, and I’m sure they
were quite time-consuming to create.
Many of the previous comments make good points (I’m not sure I
agree with the one-size-fits-all line spacing technique, either) but
I certainly welcome the dialog and any new insights into handling
typography in this clunky thing we call a web browser.

EMBED

20.

Meryl K. Evans 9:21 pm on November 20, 2007

@Brad Kemper: “Math” and “Maths” are both correct, as they are
both colloquialisms for “Mathematics”. “Maths” is the form more
commonly used in non-American english speaking countries.
Richard Rutter is from the UK, hence, “maths”.

EMBED
21.

Michael Christopherson 10:02 pm on November

20, 2007
Like Derek, I’m also curious why there is no mention of the
keyword method. It provides consistent, resizable text, and at the
time of this writing, it has been tested in a wider array of browsers
and platforms than the method suggested in this article. See the
Yahoo! UI Library for a detailed description:
http://developer.yahoo.com/yui/fonts/

EMBED

22.

Daniel Skinner 10:33 pm on November 20, 2007

Thanks for this. I have been looking for a good introduction to the
best way of using em’s for a while now. I am now ready to go an
apply these techniques to my websites.
Thanks again,

EMBED
23.

Jeffrey Zeldman 11:10 pm on November 20, 2007

@derek allard and @Michael Christopherson
The “keyword
method”:http://www.alistapart.com/articles/sizematters/ was
actually introduced by Todd Fahrner in A List Apart in May 2001.
Mr Rutter *does* refer to that method (and that article) in his
article. The problem with keywords, he says, is that they are
imprecise—by which he means, different browsers interpret them
differently.

EMBED

24.

Mark Dionne 12:04 am on November 21, 2007

Thanks for drawing attention to this issue. As one with imperfect
vision, I have my browser set to 24 points default. I constantly
run into problems where text is poured into boxes that are sized
in pixels, and it just does not fit. Go to slate.com and hit CTRL +
several times (in Firefox) to see what I mean.
Even worse are sites that open up text in a fixed size popup
window, with the Submit button at the bottom and no scroll bar.
It might work at the default font size, but not with anything
bigger.
 EMBED

25.

Mark Dionne 12:04 am on November 21, 2007

Thanks for drawing attention to this issue. As one with imperfect
vision, I have my browser set to 24 points default. I constantly
run into problems where text is poured into boxes that are sized
in pixels, and it just does not fit. Go to slate.com and hit CTRL +
several times (in Firefox) to see what I mean.
Even worse are sites that open up text in a fixed size popup
window, with the Submit button at the bottom and no scroll bar.
It might work at the default font size, but not with anything
bigger.

EMBED

26.

Voyou Desoeuvre 12:09 am on November 21, 2007

The point about setting line-height with units to keep it consistent
is very interesting and useful; but I can’t believe we’re _still_
seeing people advocate setting a default text size less than 100%.
The reason browsers have such a large default text size in the first
 place is to compensate for clueless web designers scaling down
the text; carry on scaling down the text, and the browsers will just
keep increasing the text size so that people can actually read the
damn page.
The number one complaint I hear about web pages, by quite some
distance, is that the text is too small. It’s nice that you put in some
effort to allow people to scale the text if they need to; why not just
leave the text at the user’s default size? If the user really hates
16px text, they can find out how to change it but, I suspect, most
users are much less bothered by text that’s bigger than needed,
than by text that’s unreadably small.

EMBED

27.

Jake Grinsted 12:13 am on November 21, 2007

Please forgive a beginner if this question is off-base, but I was
wondering why percentages can’t be used? Once the body is set to
100%, why can’t all other font-size declarations use percentages?
Aren’t ems just relative to the parent element anyway?
And, on a somewhat related note, is the use of points necessary
for print style sheets? Or does the author’s method print as
consistently as it displays without a separate font-size
declaration?

EMBED
28.

Michael Christopherson 1:34 am on November

21, 2007
@Jeffrey
Sorry for the confusion. The method I’m referring to, which I
inappropriately called The Keyword Method, is a bit different
than Todd Fahrner’s original method. I’m not sure if it has a
name, but it involves a combination of keywords and percentages
to achieve consistency across browsers. “Yahoo!‘s
version”:http://developer.yahoo.com/yui/fonts/ of it contains a
nice pixels-to-percentages conversion chart.

EMBED

29.

Kaspars Dambis 2:38 am on November 21, 2007

The idea of *pixel perfect* vertical rhythm is *not* what the
*vertical rhythm* is about. And it is the same with font sizes—as
monitors have more (and different) number of pixels per inch
(especially on laptops) it becomes unnecessary to have equal and
pixel perfect font sizes among all browsers, displays, monitors
and devices.
Vertical rhythm is about *contrast*, points of *reference* and
*flow* of the elements. There are many layout
 “examples”:http://bjorkoy.com/blueprint/sample.html where
“text doesn’t”:http://clagnut.com/blog/348/ look harmonic (or
could be improved) although their heading and text spacing
follows certain logic of math.
Web designers should forget about the absolute values and start
to think in relative terms (which makes the web design different
from the print). Design and composition in general is about the
_harmony_ and _relationship_ of different elements of
information.
Therefore, it would be very useful to look at the text sizing from
the perspective where element weight, line spacing and margins
are more important than the ability to convert between pixels,
ems and percentages.
I have made a collection of “Konstruktors CSS
snippets”:http://konstruktors.com which include styles for basic
typography and fluid grid/column based layouts. The typography
part is based mainly on visually sound element contrasts—“view
an
example”:http://konstruktors.com/WordPressTheme/SansserifR
acer . Another good example is
“Tripoli”:http://monc.se/tripoli/examples/sample_f.html
At the same time there is no such thing as the perfect font,
heading or line-height size. The designer has to decide with her
own set of reasoning, which might even be unknown to the
regular “viewer”. And this is exactly why design is so interesting
and exciting.

EMBED

30.

Ben preece 2:48 am on November 21, 2007

 Personally, my impression is that text sizing in CSS is a bit of a
mess.
Sizing in ems seems silly, because ems are a measure of
horizontal distance, not vertical distance, and for different fonts
the horizontal-to-vertical ratio can vary.
Pixel sizing might make sense when trying to match text size to a
fixed-size image, but really nowhere else.
Ideally, I think we’d all size our text in points, then any browser at
default font size would take screen resolution into consideration
and display the text perfectly just as it would appear on paper at
the same point size.

EMBED

31.

Philippe Wittenbergh 6:52 am on November 21,

2007
(reply to comment 30).
That is where the ‘ex’ would be very useful. Sadly,
implementations differ quite a bit.
WebKit (Safari) and Gecko do one thing (the most correct one:
the ex is based on the x-height of the specified font) where as
Opera and Trident (iExploder) do it more simple: 1em = 2ex.
Strictly speaking, neither are wrong (are allowed by the spec). The
Gecko/WebKit method is more precise and sensible.

EMBED
32.

Adrian D 7:23 am on November 21, 2007

Scaling based on the default size to get accurate pixel results
seems a strange concept me. If you need pixel-precision then px
units seem the natural choice. Whilst it may have been a good
compromise to use ems or percentages five years ago due to IE6’s
dominance, IE7’s page zoom allows pixel-sized text to be resized
whilst keeping it in proportion with image sizes, and other
browsers employ a range of other text-resizing methods that are
not affected by px units. Firefox for example, lets the user set a
minimum-font size.
The other problem is if a user has changed their default size to
something other than 16px — which is something I would like to
change to 14px so that I can more easily read websites that have
not set a size — then, as encountered with Safari’s default size for
monospace, all bets on your pixel accuracy are off.
Also, isn’t it a little rude to be effectively saying “I don’t know
what your default text size is, but I want it smaller than what you
have chosen!”?

EMBED

33.

Ben Sekulowicz 1:05 pm on November 21, 2007

 bq. Perhaps readers will forgive this innovator for continuing to
innovate on our behalf, and will now actually consider what he
has to say in the article, instead of criticizing him for not sticking
with the rule he himself gave us.
Hang on there ... The article specifically states that the methods
proposed lead to difficult calculations when using EM sizing
throughout a site. So if, in the forum that you are promoting, a
commentator states that they prefer the original methods because
of such a problem, and doesn’t see the benefits, they get sarcastic
responses?
Without trying to provoke massive argument or come across as a
dick, and fully admitting that I had no idea who came up with the
original 62.5% idea, (if such a thing can be credited to one
person), what the hell is the point of allowing people to post and
discuss the merits of different techniques?

EMBED

34.

Fred Seltzer 2:44 pm on November 21, 2007

This sort of inventiveness and creativity should be put to a higher
purpose than moving around letters around a page.
It’s been fifteen years, at least, since WYSIWYG was introduced to
the masses for desktop publishing et cetera. That web techs
should be fussing over tenths of a percent in a declarative page
description language is just so 1970’s. Shades of Troff, indeed.
In any case, writing CSS as plain text is error prone, and error
messages are usually nonexistent. We should be using property
sheets for defining styles.
 The techniques for producing consistent, multi-browser text
sizing should only need to be known by those few programmers
building WYSIWYG web writing systems.

EMBED

35.

Tom Leadbetter 3:25 pm on November 21, 2007

Well I actually enjoyed the article. Thanks for the great
screenshots and valuable information for cross-browser
differences.
I use ems for font-size and have to admit that I have not used the
62.5% technique before. So I’m now off to have a play with that…..

EMBED

36.

Stephen Down 5:11 pm on November 21, 2007

None of this addresses the fact that *your* text on ALA is too
small!
Body text should _never_ be rendered outside the range 90% to
110% (or 0.9em to 1.1em, if you prefer). If you find that, on your
 computer, it appears too large, then you should change the
settings on your computer.
I have my computer set to display the text at the size I want. Your
0.8125em is too small, so I have to enlarge it to make it legible -
this is _not_ good practice!

EMBED

37.

Meryl K. Evans 6:47 pm on November 21, 2007

@Stephen Down: What’s too small for some is just right for
others. We don’t aim to please everyone (and we’d be silly to
attempt it). Changing the text sizes on our computers doesn’t
make much sense. We need to keep our setups at the defaults so
that we can approximate a baseline for testing.
We’re trying to make it comfortable for as many people as we can.
We’re sorry if you fall outside of that, but that doesn’t mean our
practices are bad. The fact that you _can_ resize it _is_ good
practice.

EMBED

38.
 Jonathan Kemp 7:59 pm on November 21, 2007
On the setup I use everyday, there IS a difference in font sizes
between Mac and PC when they are both set to the defaults. On
my PC, which sits right next to my Mac, the fonts are bigger than
they are on my Mac. So I do not get that the fonts are the same
size. Does anyone else experience this or am I the only one?
In addition, I would also like to know why you can’t use
percentages to solve this problem. It seems to work for me.
I did like the article though.

EMBED

39.

Stephen Down 8:59 pm on November 21, 2007

@Brad Kemper:
bq. Every other browser on Earth can enlarge or reduce text that
is set in pixels. I will continue to specify my fonts in pixels, and if
anyone wants to resize it, then they can zoom the whole page or
download a more capable browser.
I’m usually one of the first on the IE-bashing bandwagon, but I
think it’s wrong to do that here. IE _are_ following the
specification by not resizing text specified in pixels, and other
browsers are _wrong_ to do so. Pixels are for when you
absolutely need the text to display at a particular size, and
browsers should respect that. Text that can be resized should be
set in ems, percentages or keywords.
But regardless of the rights and wrongs of it, you’re showing a
very negative and unhelpful attitude. The vast majority of people
using the internet, and particularly those in the 90% of people
who use IE, don’t care about web design, they don’t care about
web standards, all they want is to be able to browse websites. If
you are deliberately stopping people from resizing body text by
 using px measurements then you’re just as bad as the people who
omit alt text and who use Javascript popup links “because anyone
who can’t cope with that doesn’t deserve to use my website”, or
whatever crappy justification they come up with.
As web designers, we have a responsibility to clients - to design a
website that serves their organisation’s needs - a responsibility to
the general public - to design a website that allows them to access
the content and services therein and that is easy and pleasing to
use - and a responsibility to the web design community - to
promote and use best practice, to continually raise the bar, deliver
the best we can, and encourage others to do the same.
There’s no place in there for having a tantrum about people using
unsatisfactory browsers.

EMBED

40.

Dusan Smolnikar 9:05 pm on November 21, 2007

About the monospace ‘problem’ - Safari and Firefox both keep
monospaced fonts at 13px. Safari 3 on OS X does as well. I’m not
100% sure about 3a mentioned in the article, but I believe it used
13px as well.
If like me, you don’t want to revert to pixel-sizes to bypass this,
“here is my solution”:http://dusan.fora.si/blog/normalize-
monospaced-text-font-size to the problem. But it does use some
css hacks and might not be future proof.

EMBED
41.

Stephen Down 9:17 pm on November 21, 2007

@Voyou Desoeuvre:
bq. The point about setting line-height with units to keep it
consistent is very interesting and useful; but I can’t believe we’re
still seeing people advocate setting a default text size less than
100%. The reason browsers have such a large default text size in
the first place is to compensate for clueless web designers scaling
down the text; carry on scaling down the text, and the browsers
will just keep increasing the text size so that people can actually
read the damn page.
It’s nice to know I’m not the only one banging on about this!
Jason, I see what you’re saying, but I still fundamentally disagree.
I have the text on my computer at the size I find most comfortable
to read. On Opera, ALA appears fine, if a little on the small side.
On IE6, it is completely illegible.
Yes, it’s good that I can change the size - but that’s not good
practice, it’s simply working around bad practice.
Browser chrome is there for a purpose. The settings to allow
people to set a preferred font size are there for a purpose. Once
someone has set their preferred font size, all websites should then
be legible without having to further fiddle with things.
The main problem, as far as I can see, is that by using ems, you
stuff things up for IE users who have their text set to anything
other than ‘medium’. I might be wrong about the cause of this,
but I think it’s a bug in the way IE treats ems at non-medium text
size.
eg, on another site, if I resize from ‘medium’ to ‘smaller’, the text
reduces by about 25%, and retains a sensible size ... but if I resize
from ‘medium’ to ‘smaller’ on ALA, the text size *halves*, which is
why it becomes illegibly small. Other changes result in similarly
dramatic changes - at ‘largest’, I only get about 12 lines of text on
the screen.
 EMBED

42.

Mike Cherim 10:07 pm on November 21, 2007

When using only EMs, IE creates a new baseline for the text and
enlarges and reduces from said baseline (instead of the original
baseline dictated by the browser’s default size). It is because of
this anomaly that the text is reduced and enlarged beyond what
would be considered normal, and what is offered by other
browsers.
In other words, if “Larger” is 150% of a 1em baseline, “Largest”
will end up being 200% of the new 150% baseline, instead of
being 200% of the real 1em baseline. This, of course, makes the
enlarged text abnormally large. And the same works in reverse for
text reduction.
This is a bug, but one that’s easy to get around. The rule: Never
start sizing text in EMs in the style sheet (even if you want to use
EMs). Always start with percent, as in 100% (instead of 1em).
Doing this normalizes this baseline font size bug in IE and allows
developers to use EMs anywhere else in the CSS file. So
something like this is the cure:
body {
font-size : 100%; /* Set a cross-browser baseline in % */
}
#wrapper {
font-size : 0.9em; /* Then size the text as you want */
}

EMBED
43.

Mike Cherim 10:08 pm on November 21, 2007

Hopefully what I just posted can be fixed to look as it should.

EMBED

44.

Patrick Cote 10:50 pm on November 21, 2007

Just a couple thoughts…
I am both a web and print designer and I like to believe I know a
fair bit about typography. Why web designers/developers have
become obsessed with everything being set to a rigid baseline grid
is beyond me. Where did you get this from? If you know anything
about print you know that you don’t set all text to the same
baseline grid—it looks like crap. It’s bad practice. It doesn’t make
sense.
I also don’t understand why everyone is so obsessed with having
such control over the size of text. Aren’t we supposed to be over
this already? I agree fully with those that have said that body copy
should appear at the user’s default size setting. End of story.
That’s the point isn’t it? I’m 32 and I find the text on this site a
little small. God knows what I’ll think of it when I’m 52. Why are
we trying to figure out better ways of telling users what we think
they want?
 When I design for print I take total control. When I design for
web I hand over some control to the user. I’m happy with that.

EMBED

45.

gabriel vivas 10:01 am on November 22, 2007

I came across this “pt” measure, that is supposed to resemble true
size (postscript points), so very common things like 9pt/12pt
could be done in that very way. I have been using this pt method
for a while; By the way, I find “ems” making a lot more sense than
pixels, meaning I find them more of a natural measure for type
than pixels. Eventhough I feel uncomfortable having to write
uncomprensuble things like: 0.873em.
anyway, I’ve seen that Pts do rezise. So I have been using them
happily

EMBED

46.

Stephen Down 3:51 pm on November 22, 2007

Gabriel,
 The main reason for not using pt for screen work is that points are
defined as a physical measurement of 1/72 inch. How that is
displayed on screen is a matter of luck rather than judgement -
Windows and Mac render pt very differently.
Yes, by all means use pt in your print.css, that’s what they do well.
But they don’t belong on screen - that’s why we have percentages,
ems, keywords and pixels.

EMBED

47.

Housik Man 5:39 pm on November 22, 2007

Try to set (for example in Windows) different DPI in screen
settings, you will get sometimes unusable design with your
default CSS using EM’s units. The problem appears on small
LCD’s with high resolution (mostly small notebooks). I think, the
best is to let user to choose appropriate size of text (by choosing
from predefined CSS styles).

EMBED

48.

Dusan Smolnikar 9:59 pm on November 22, 2007

 But in a perfect world, where the operating system could detect
display’s dpi and set its own dpi accordingly, pt would make a lot
of sense. Such as it is nowadays, most users don’t really know
what dpi means and even a smaller percentage have actually ever
tweaked this setting.
BTW - There used to be a dpi setting in Firefox that let you
determine your display’s dpi. But I can’t find it anymore, have
they removed it?

EMBED

49.

Radomir Dopieralski 2:50 am on November 23,

2007
Ok, now we have Arial pretty much covered—but it’s a pretty ugly
and bland font—especially when you see it practically
*everywhere* today.
What I would like to see next is a technique to make the font sizes
consistent on different systems when you use a list of fonts,
because you expect that different users have different fonts
installed.
For example, this simple style:
font-family: Techno, Impact, Haettenschweiler, sans-serif;
will render at completely different sizes depending not only on
the user’s DPI setting, browser’s default font size and zoom level
and system’s hinting settings, but also on which of the fonts are
available, what arcane rules the browser in question uses to select
a font from the list, where the font files came from and the phase
of the moon.
It would be really awesome if someone found a way to deal with
it. Of course, embeddable fonts would solve this easily—but they
are only in one rendering system, and not even a web browser.
 EMBED

50.

Richard Fink 9:22 am on November 23, 2007

Good to see someone hacking out hard comparison data.
Confirms what I’ve found on my own - font rendering is now
remarkably consistent from browser to browser.
A one-whitespace-fits-all line-height (leading) regardless of font
size flies in the face of readability studies measuring both speed
and user-preference. Disregard.
Line length is an issue much worth thinking about.
Plus tightening the word-space property. (Any data there?)
And, very occasionally, letter-spacing.
Lastly, how about the ability to intelligently justify text,
hyphenation and all?
Let’s go for it! Solid work, this.

EMBED

51.
 Miriam Richardson 11:29 am on November 23,
2007
This is a great article, thank you! I have been feeling the need for
an update on Owen Briggs work, and it is fantastic someone has
done that work for us.
With an old PC screen sitting beside my clean, high resolution
mac-connected-monitor, the size differences in IE have been
irritating me for a while. The old monitor seems to have large
pixels, so that everything looks clunky, and it is hard to know
what is the monitor, what is a PC-talking-to-a screen issue, and
what is a browser issue.
So thanks for some hard facts/screen shots and a new formula.
All I have to do now is get used to figuring the maths with nested
ems. And decide where I stand on the line-height issue.

EMBED

52.

Stephen Down 4:55 pm on November 23, 2007

> For example, this simple style: font-family: Techno, Impact,
Haettenschweiler, sans-serif; will render at completely different
sizes depending not only on the user’s DPI setting, browser’s
default font size and zoom level and system’s hinting settings, but
also on which of the fonts are available, what arcane rules the
browser in question uses to select a font from the list, where the
font files came from and the phase of the moon.
Given that the font will display differently on different machines
because of the user’s size and zoom settings (which is a _good_
thing), why make a fuss if it displays differently for other reasons?
You’ve already found a reason why the design has to be flexible,
so just let go and accept that there may be a few more differences
in the way the text is rendered.
 EMBED

53.

Martin Petrov 11:36 pm on November 23, 2007

Put this on your home page:
Is the text on alistapart.com too small?
A. Yes
B. No

EMBED

54.

Martijn ten Napel 11:45 am on November 24, 2007

I haven’t read ALA for a while, and I’m pretty shocked by the
comments. What is wrong by showing manners and using a bit
more language to present your criticism other than ‘idiot’? It
looks like communities are going the same way as USENEt did:
the drain.
Apart from that, one commenter expressed that he is happy to
give control to the user, which is something I am for myself.
However, I feel that using this method the comtrol is in the hand
of the user: if you change your default font sizes in your browser
 preferences than you have to live with the consequentes. Scaling
pages up and down will render proportional typesetting, which is
what this article aims at.
I do not like page zoom like Opera and IE7 display because of
scrollbars, so this method gives a bit more flexibility. Well written
and very clear and tested examples!

EMBED

55.

Andrej Telle 7:29 pm on November 24, 2007

When testing the 62.5% rule really at 62.5%? When testing font-
size output in different browsers I found that Opera displays the
font at the next smaller possible size at 62.5%.

So I tried to bring it up to 63% which worked out perfectly for all

browser (ie 6-7, firefox, opera).
Anyone know the reason for this?

EMBED

56.
 cristobal castro 4:10 am on November 25, 2007
the funny thing is that only one person talked about the difference
across browser’s platform, the truth is this:
safari mac and safari pc = no changes in font sizes
firefox mac and firefox pc = big changes in font sizing
conclusion:
safari most consistent browser across pc/mac platform.

EMBED

57.

Chris Hester 4:12 pm on November 27, 2007

Firstly, Stephen Down wrote defending IE’s non-resizing of fonts
set in pixels: “Pixels are for when you absolutely need the text to
display at a particular size, and browsers should respect that.”
Not this argument again. All I will add is this: what if the text size
chosen is considered too small by the user? Who dictates that
they cannot choose to enlarge it? No-one should! To hell with
fixed pixel fonts. Even IE5/Mac could resize fonts in pixels. (And
even IE6 can enlarge pixel fonts if you use ‘zoom:’ in your
stylesheet, or create a User Stylesheet. So it seems more of a bug
than a deliberate feature, though I could be wrong. Anyway, since
it is the only browser to do this, we can ignore it.)
Secondly, the person who wrote about enlarged text not fitting
boxes in Firefox will be glad to know that Firefox 3 (released in
beta form as I write) can enlarge the whole page. Of course now
there are people complaining that they only want the text
enlarging! Well an option for either method would be good. But at
least Firefox has now joined the ranks of Opera and IE7 in
intelligent page resizing. Zoom on!
 Thirdly, I am viewing this site with the text enlarged myself,
because I agree with others who say the text is too small. Just my
opinion of course.

EMBED

58.

Ville Takanen 5:24 pm on November 27, 2007

T really liked the article. Thank you.
I got tired of calculating the ems and wrote a small php-script to
calculate them for me
http://www.sange.fi/~vtakanen/typography/linefeed.php
Caveat: A work in progres.

EMBED

59.

Christian Sonne 9:46 pm on November 27, 2007

.. and not the one you might think :-)
The syntax used is not only wrong, it will cause IE to not render
anything after the comment - it’s never considered closed…
 instead of
<!—[if !IE]>—>
<!—<[endif]—>
you should have used
<!—[if !IE]—>
<!—[endif]—>
Ran across the problem as I was using your guide, and suddenly,
IE7 did not render my page at all - after changing the conditional
comment as described above, it worked perfectly…
Also, if one considers quirksmode.org a reliable source, read here:
“http://www.quirksmode.org/css/condcom.html”:http://www.qu
irksmode.org/css/condcom.html

EMBED

60.

Sam Sutton 2:01 am on November 28, 2007

As was touched on earlier, I think this kind of debate points out
the limits of CSS as a formatting model - the tinkering with CSS to
produce consistent effcts is a rewarding challenge - but ultimately
I always feel as though both HTML and css are already
anachronistic, in terms of what they were originally purposed for
- styling text documents - and what they are increasingly called on
to do - i.e. structure user interfaces for web services.

EMBED
61.

Wayne Johnson 12:01 pm on November 28, 2007

I been asking this question to myself a thousand time and this is
one of the best examinations of text sizes. Given me great insite
into building my next website.
Thanks

EMBED

62.

Stephen Down 4:09 pm on November 28, 2007

bq. Not this argument again. All I will add is this: what if the text
size chosen is considered too small by the user? Who dictates that
they cannot choose to enlarge it? No-one should!
My view on it is this:
You should be able to set a _minimum text size_ in your browser
settings, so that no text will ever be rendered smaller than, eg,
12px (or whatever else you consider the minimum that you can
read). This would be the equivalent of a user !important, and
would override anything the website says or does.
You should be able to zoom the page (text, images and layout) to
enlarge or reduce it as appropriate. Opera seems to do this better
than IE7, but that may just be because I’m more familiar with it.
 The designer should be able to make concrete layout
_suggestions_ that the browser will respect where possible. That
means that there are *some* occasions where the pixel size of text
is important to the layout - eg, because it has to fit with images
that are necessarily sized in pixels.
That’s why we should *not* use px for font sizing as a matter of
course - because it should be reserved for those occasions when
you absolutely need the text to be displayed at that size - 99.99%
of the time, ems or %s are the right way to go.
The main reason that browsers do support resizing of text in px is
because they are trying to compensate for the idiocy of designers
who have inappropriately specified text in px across the board.

EMBED

63.

Kendall Conrad 5:07 am on November 29, 2007

I personally don’t understand some designer’s desire for such
pixel perfect designs. Web pages should be more fluid than that
(of course there are exceptions). I personally use em and fix the
IE issue by setting the body font-size to 100%, as was mentioned
in an earlier post. For the main content I generally use 1em
because that should be the default. I don’t do any .865em or
whatever, I just make things relative, often .9em or 1.5em.
I don’t care much for the zoom option in some browsers, but I do
think it would be good for browsers to have both options of zoom
and text size in-/de-crease.
Just as another vote, I find ALA text size too small. I’m currently
viewing the page 3 notches up, though my eyes are tired, but
usually use 2 notches for the site and I’m in my mid-20s and have
good eye sight. Too many sites are decreasing their font-sizes. The
default 16px is there for a reason like others have stated. Though I
 find it funny that the texarea box for writing a comment is quite a
bit larger than all of the other text on the page.
Overall, nice article and good things to think about.

EMBED

64.

jay mcdonald 3:42 pm on November 29, 2007

I first settled on pixels for font sizes after reading the original
release of Zeldman’s DWWS. Ems have a certain attractiveness, in
that they let you set a base size and then set everything else in
relation to that. That flexes nicely, if I want to rework a sheet with
a new base size and have everything change proportionally
without having to touch all declarations.
However, this is the sticky bit that I completely don’t understand:
What’s with the compounding on nested items? Why in the world
would I want to embrace a typesetting standard that requires me
to keep track of where in the document hierarchy a piece of type is
and then CALCULATE the proper setting to keep the type AT
THE SAME SIZE? That’s crazymaking. The push for standards
was about stopping the madness, and it seems this is just an
exchange of one form of madness for another. “Stop all the
browser code forking!” (Hooray!) “Compute arcane, essentially
meaningless size settings (1.375em
?), and make sure your nested items have their own settings (for
each level of nesting) to compensate for compounding!”
(Hooray?)
This is progress? All of this to accommodate a segment of users
who have chosen to use a tool that doesn’t do what they want?
That sounds like a personal problem. Whatever happened to
individual accountability? Why should an industry adopt an
awkward, recursive practice of font sizing to fix something these
 users should be fixing themselves? Any self-respecting
programmer would snort and walk away. Any self-respecting
designer would just decide you’re crazy.
Perhaps this is related to the notion that several have brought up
about the rigid baseline grid being a typographic anomaly that
has grown up in the soil of typographic ignorance on the web.
Maybe those who are valuing “upsizing for all! (even apathetic IE
6 users)”? over and above sensible methodologies are mostly
politically correct nouveau-web fanboys who are ignorant of the
older, and more established streams of thought coming from the
worlds of typographic design (dating to at least Gutenberg), and
programming (Donald Knuth, anyone?) that inform these issues.
I think I’m sticking with pixels. Page zoom is a good solution. IE6
users are the only ones left out. Anyone with vision problems
should do the research to solve their problem by changing
browsers to one that does what they want. If they don’t, then it’s
their bad, not mine. Web makers shouldn’t have to jump through
flaming hoops backwards to accommodate apathetic users who
want to complain about type sizes when the problem is their
passivity towards solving their own issue.

EMBED

65.

Carsten E 11:47 am on December 01, 2007

I try avoiding putting styles (like fontsize) on the P-tag because
CMSs don’t always relyably produce the desired clean HTML-
output. Sometimes the editors used in CMSs produce a P-tag
around the content, sometimes they don’t. If you try to catch this
in your templates by putting a P around where the content is
loaded, you will get invalid code when de editor does produce the
P (P within P).
 So I try to put these styles on the surrounding DIV. Did anyone
work out the alteration of this code to suit this need?

EMBED

66.

Noel Jackson 10:36 am on December 04, 2007

Someone had to do this testing - I’m glad to say that my non-
scientific testing correlates to richards findings. Now I can rest
assured that there is a proper way to set sizes in css - ems baby,
ems.
Plus, I think guttenburg would be happy. The pixel shall not win
this battle. ;)

EMBED

67.

T.J. L 6:09 pm on December 18, 2007

I used this article while designing a site I’m working on now. I
have always had problems with (em) and cross browser quirks,
this is great for make those readily apparent. Previously I had
giving up on em just because of all the browser issues associated
 with it. This method has proved flawless so far on the site, and I
will probably use it on all subsequent sites I design.

EMBED

68.

James Thomson 12:12 am on December 25, 2007

Another awesome piece of research and testing, cheers Richard. If
the article upsets me in one way, it’s in realising that this sort of
article should only be enforcing the test we’ve already carried
out…unfortunately time and resource doesn’t always permit so it’s
thanks to you again - this article will be passed around our
developement team and adopted as apart of our coding standards.

EMBED

69.

Mason Barge 7:24 pm on December 31, 2007

Using ems (or any percentage method) to resize fonts pretty much
guarantees sub-optimal design and legibility. This current
“received wisdom” of web design, focusing so hard on technical
aspects, generally fails to recognize the nature of pixel-rendered
fonts.
 Fonts cannot be resized successfully simply by using ems or any
other percentage method. They are not like svg objects. Fonts are
an art form and the size in pixels is critical. If you render a font at
80% that was drawn at, say, 18px in height, you do not get the
same font 20% smaller. You get a different font that is usually
less legible and less attractive, and is often downright ugly and
hard to read. Resizing fonts by using percentage reduction is
tantamount to resizing images by using percentages.
If you want your typeface to look good at different sizes, you have
to retain style control. This means using fixed font sizes and
providing alternate font sizes yourself, which is fairly easy to do
through a server-side script.

EMBED

70.

Loren Knack 12:59 am on January 03, 2008

Thanks for posting up your article. I’ve used the test pages you
provided and looked at them in FF2/IE7 on a PC. Using the EM
method you’ve described, there is still a large font jump in IE7 on
the PC. Has anyone else noticed this, and is there a recommended
cure?

EMBED

71.
 Chris McKee 4:54 am on January 04, 2008
Fantastic article, but on thing really stuck in my head as I looked
thorough the countless screen-shot examples (cant beat pictures),
the difference that ClearType makes with browser rendering in
comparison to the mac fat’n'furry soft rendering.
I get that its a personal preference, but wouldn’t it be great if
Apple and MS could just agree that fonts should display as they
were intended to by their designers.

EMBED

72.

davoud tohidy 12:56 am on January 06, 2008

Hi Richard,
This is a wonderfull experiment and I would like to thank you
very much for sharing it with the world. However I have an
objection inregards to your conclusion.
First please let me draw your attention to what you have here:
The tests that you have done are based on the following
environment:
1-Tests have been done with limited number of browsers as you
pointed it out yourself but they are not the majority of the
browsers as you mention in your article.
2-Tests have been done in two operating systems.
3-Tests have been done with one font-family.
4-Tests have been done in a two column layout.
5-Tests have been done with XHTML strict doctype and
charset=utf-8
So what is the objection?
Even though I look at the conclusion of your article positively
(and BTW i have experimented myself in some part of my site)
however I believe it only applies to your experiment and cannot
be generalized as you have generalized in your article.
Clearly there are other factors which affect the rendering of a web
content. The structure of web content and the environment in
which the web content is present are the most important part
affecting the rendering process.
As you know It is possible for a content to be rendered correctly in
one layout / browser/platform however with problems such as
overlaps in the same layout but in different browser/platform or
in different layout / browser/platform.
So if we use another layout or structure other than two column
layout or another font-family, etc. it is possible to see some
inconsistencies or it needs to be proved by some more
experiments that there are no any inconsistencies.
So basically it is not enough for a text or any element to be a cross
browser/platform text / element. It also needs to act properly in
relation to it’s neighborhood preventing any layout stability
problems when viewing normaly or when resizing the browser’s
window or applying zoom etc..
That is why I have defined the layout stability on my site located
at cssfreelancer.awardspace.com to address this issue.
As you can see in my site, I have:(I am aware of that 62.5% thingy
:), I have experimented the following too)
body { font:96%/1.7 georgia,serif}
Line-height (unitless for body but in ems for the rest of the
elements)
Then I have two sections. 1-Navigation elements 2-Rest of the
document.
I have set the font-size in ems for Navigation elements and no
font-size declaration for the rest of the document. That is set for
all browsers.
With the above combination of font-size and line-height, I have
experimented my layout using browsercam’s online service with
different browsers including IE6,IE7, AOL, Camino, Konqueror,
Different versions of (Firefox, Netscape, Opera, Safari,Mozilla, )
on different platforms such as Windows Vista, Windows XP,
Windows 2000 Professional, Linux and Macintosh. The screen
 captures are available at the following
URL:
http://www.browsercam.com/public.aspx?proj_id=389986
My experiment proves that, for my layout and with my test
parameters like font-family etc. setting the above mentioned CSS
rules turns out to be a consistent cross browser and platform
solution.
However I still can not generalize it and I am still debating on it.
Any comments in this regard would be greatly appreciated.

EMBED

73.

Greg Hostetler 10:03 pm on February 07, 2008

@Loren
I had the same problem and could not figure out the
problem. But since I have a large monitor and bad eyes I changed
my dpi to 120. And apparently IE7 takes that into account when
displaying fonts. All is good now that I switched my font dpi back
to 96.

EMBED

74.
 Felix Miata 5:18 am on March 07, 2008
@article base case - "For most people (designers, clients, and
their customers) 16px is too large for body text" is a rude and
unsupported assertion. While empirically it can be said it is quite
evidently true of web designers, the same cannot be said of the
other two groups. The "size" of 16px has been creeping down for
over a decade as the average PPI has been creeping up. While it
may well have been true over a decade ago that most people
agreed the defaults were too large, there is no published evidence
anywhere I have found to support that assertion against the
average current environment. OTOH, there is at least some
published support in contradiction
“http://www.useit.com/alertbox/designmistakes.html”:http://w
ww.useit.com/alertbox/designmistakes.html and recommending
that user default size be respected
“http://www.w3.org/QA/Tips/font-
size”:http://www.w3.org/QA/Tips/font-size to be found on other
than my own web site.
Konqueror defaults to a pt size that is less than 16px when the
DPI is 96. All IE browsers default to 12pt, not 16px. 16px only
appears to be its default as a consequence of the a default M$
system setting of 96 DPI. Use of other than 96 is common on
recent and current laptops (which, by the way, have been
outselling desktops for several years), which typically have a
considerably higher than average PPI and need OEM correction
to avoid illegible text on their already small displays.
Manufacturers have made 120 DPI a virtual default for laptops.
The result is IE and other browsers whose defaults are not set in
px give users who have not made further corrections 20px @ 12pt
instead of 16.
@article&more; (Richard R, David L, others) - Line-height set
other than unitless is a bad habit. That only unitless carries down
the cascade as a factor rather than as a previously computed value
is a good thing. It means when zoom or minimum font size are
employed by the user’s agent to turn your mousetype into
otherwise legible text that that text is not constrained to a space
into which it cannot fit without overlapping the text above and
below it. See “http://mrm.no-ip.com/auth/line-height-
inherit.html”:http://mrm.no-ip.com/auth/line-height-
inherit.html to understand the problem.
@1 (Kari P) - IE em sizing problems are complicated. As
answered earlier, setting a % size on body eliminates IE’s basic
compounding problem. What hasn’t been mentioned is that the
various browsers round differently. That means the starting point
can be different right off the bat, but as they cascade and
additional sizes are added, the rounding differences also
compound. Take a look at “http://mrm.no-
ip.com/auth/Font/font-rounding.html”:http://mrm.no-
ip.com/auth/Font/font-rounding.html for more detail via a
testcase.
@5+ (James S, more) - No one here yet mentioned a not
inconsequential result often encountered on pages using the
Clagnut/62.5% method. 62.5% is really convenient only for
designers who think they need to size things in relation to this
variable and unknown size thing called a px. Invariably these
designers prefer text in their work to be a smaller size than
average people are comfortable with. For defense against this
rude designer behavior, modern user agent makers include
functions like text zoom, page zoom, and minimum font size.
When text zoom and/or minimum size are applied by user agents
based upon the Gecko rendering engine, the ostensibly intended
effect is multiplied in a manner similar to IE’s font sizing of ems
that aren’t applied against an ancestral % size. The effect is truly
overlarge text (based upon the visitor’s preferred size), often
producing overlapping and/or hidden (inaccessible content).
“http://mrm.no-
ip.com/SS/Clagnut/eonsSS.html”:http://mrm.no-
ip.com/SS/Clagnut/eonsSS.html demonstrates the problem with
screenshots, but you can easily see for yourself by setting equally
default size and minimum size to a size significantly more than
16px and then visiting a 62.5% site, such as
“clearleft.com”:http://www.clearleft.com.
@26 (Voyou D) - Please stop repeating the mantra. The defaults
stopped being "big" years ago. For most web browsers the default
size measured in px has not changed for at least 12 years, and
probably much longer. Because of the decrease in average PPI
over the years, the apparent default size has been decreasing. To
the rest of what you wrote, well said.
@32 (Adrian D) - It isn’t a little rude, it’s a lot rude.
@37 (Jason S M) - Not only does changing your browser defaults
not not make perfect sense, you’re derelict in your testing
thoroughness to not be constantly changing them to emulate the
wide range of possible user conditions. There are too many
variables in user environments to assume that users have one
resembling your own, regardless what the system and browser
settings were when you got your own hardware. Assuming any
user setting to be wrong and in need of arbitrary adjustment by
someone with less than 100% of the situational facts is nothing
short of rude.
@39 (Stephen D) - Web browsers are user agents, not web page
author agents. Those incapable of accommodating user wishes
and needs are broken. It doesn’t matter what your design requires
or the CSS specs seem to say. If I can’t read it, it’s worthless.
@48 (Dusan S) - Modern open source operating systems can and
do detect display DPI, thus rendering text on screen sized in pt
exactly the same size as when printed. The problem is that screen
resolution falls short of print resolution, while the average
distance between text and user’s eyes is considerably greater for
screens compared to books, magazines and newspapers. Text on
screen usually needs to be physically bigger than printed text in
order to be equally comfortable to read, or even legible. Firefox
for Linux and Mac do allow a different assumed DPI, but there is
no UI for changing it. Type about:prefs in the urlbar, then dpi in
the search box to find the pref.
@55 (Andrej T) - Decimals in font size rules are ignored by IE.
62.5% is treated by it as 62.00%.
@62 (Kendall C) - If you’re in the design business, you’ll probably
find yourself back on ALA often. Make yourself a user stylesheet
that applies exclusively to it via Gecko’s @-moz-document facility
and you won’t know about its tiny text until it gets a CSS overhaul
that breaks your overrides.
@68 (Mason B) - If you’re using a decent modern display better
than the median, you have enough PPI that small differences in
font sizes should produce no apparent qualitative differences. I
don’t ever find smaller than my default fonts easier to read,
regardless how many px it took to render them, or how good they
"look". Indeed, if you render a font at "font-size: 80%" that was
18px in height, what you actually get is a font 64% in size. CSS
"size" is only nominal, not real. Real size is a function of both
height and width. A 16px character contains around 128 discrete
px, measuring around 8px wide by 16px tall. A character box
exactly 80% of 18px high would be 6.4px wide by 12.8px tall,
providing about 82 discrete px.
Be part of the solution to the problem rather than part of the
problem. Accept that 100% of the default size is best. Personal
computers are intended to be personalized. Assuming they have
 been is the right thing to do, no matter how few have actually had
it done. Just because web designers all think browser makers are
morons is no justification for assuming smaller is better for
anyone other than yourself. If the defaults are too big for you,
personalize your own PC, not mine.

EMBED

75.

Zach Harkey 7:18 pm on March 11, 2008

Jay’s comment perfectly sums up my feelings on this whole
ridiculous practice.
http://www.alistapart.com/comments/howtosizetextincss?page=
7#63

EMBED

76.

Ringo Duemke 7:33 pm on March 27, 2008

Where can i get the page zoom tool?
 EMBED

77.

Adrian Demian 10:15 pm on April 03, 2008

I still have doubts regarding the best solution of what type of font
to use. Still testing different variations.
Keep up the good work.

EMBED

78.

Michael Ayed 2:09 pm on May 11, 2008

I´ve got much problems with the text size in Ie and Firefox, too.
But this discussion and it´s including links helps me a lot.
Thanks everybody

EMBED
79.

Phillip Bicknell 2:24 pm on May 16, 2008

@61 included: “That means that there are some occasions where
the pixel size of text is important to the layout — eg, because it has
to fit with images that are necessarily sized in pixels.”
However, there is an easy method to size images in ems - see
http://www.wats.ca/show.php?contentid=33 for example.

EMBED

80.

Diane Vigil 12:15 pm on May 17, 2008

You’re right that keeping track of the math percentages with ems
can be tricky. Luckily, with a good handful of browsers for testing,
and a logically laid out stylesheet, it gets much easier.

EMBED
81.

Tabitha Bingham 1:00 am on May 28, 2008

Being that I don’t have the grasp of CSS that the author surely
does, i’m sure my comments might not be appreciated….. I am of
the opinion that it is best to set the pixel size absolutely as most
sites (should) have a significant amount of content. As a
designer, I prefer knowing exactly where every letter is going to
appear in relation to every graphic. It helps me to visualize where
images should or shouldn’t go and more. Of course, I am a bit old
school in my methodology, but it is still my preference :)

EMBED

82.

Vital Bodies 9:01 am on May 30, 2008

I liked the effort that was put into this article. That was a whole
lot of screen captures and thought.
*Thank you!*
I came to this site as a whole, looking for the answer to a
question:
How can I/we create documents, that might be one or more pages
and be shown one any platform (I use Ubuntu) or browser, print
correctly onto pages (at the right DPI for images for example, over
72dpi), scale to work for those with vision needs/screen
resolution/device…
and
not have to rewrite/change/tweak/etc the content?
And be hyper linked together so one document can be related to
another.
I have found that using table-less valid strict XHTML code and
CSS for style while basing most (if not all) things on _em_ makes
the cross platform - cross browser challenge fairly do-able.
_I was inspired towards this back in the CSSzenGARDEN days._
_Thanks to all you designers that made that site rock!_
But then there is printing and portable devices and better
accessibility.
One only lives so long. How many times do we really want to
recreate the same document/content for a new device, browser,
printer, email or software just because a decade has passed
-or MS has some new notion of how to keep people locked into
THEIR closed source-
?
As artists, do you not want to create new art instead dredging
through old documents and recreating old documents to work
with current technology?
A paper page is the size a paper page which is fixed and yet not as
and now we have many countries and thus pages sizes.
What is the best approach for the long run?
There is much ado about creating web page/site that work for
what ever is current and happening in the now like a fluid 3
column lay-out but
I am asking/questioning/yearning about content.
*NOTE:*
Even the content I write at this moment is UNUSABLE again with
out tweaking because it is coded to Textile which seems to only be
some what working and is not XHTML…

EMBED
83.

Vital Bodies 11:40 pm on May 30, 2008

Seems like the CSSzenGARDEN site slowed way down for a while
and they look like they are going strong. : )
The A List apart is an A list site for sure. Thanks again…

EMBED

84.

Michal ÄŒizmazia 4:56 pm on November 20, 2008

Table cells with multiple lines break the rhythm of the complex
example. I checked it using the “background
image”:/d/settingtypeontheweb/images/gridbg.gif

EMBED

85.
 Pieter Beulque 4:53 pm on November 26, 2008
There’s also a easy trick for this one:
An em is 16px.
10px equals 62.5% of 16px, or an em.
So if you put the font-size for the body element to 62.5%, it’s easy
to calculate the other ones.
E.g. if you want 12px font-size, you just put in 1.2em. Because 1.2
* 10 = 12.
Regards,
Pieter

EMBED

86.

Chris-Raymond 6:42 pm on January 14, 2009

Generally, I love ALA’s typesetting, and this article was good.
However, when I went to the complex example, I noted
something that from the standpoint of readability is just plain
wrong: The same amount of vertical space before and after heads,
esp. subheads. As a reader, you need visual cues to connect a
[sub]head to the text it is heading; therefore, there should be
visibly more space ABOVE the head than below it. Not to pick
specifically on this writer—I see this all over the web.

EMBED
87.

John (The Boy) Ryan 11:00 am on June 24, 2009

A very informative article, however…
When it comes to CSS, positioning containers is the real pain.
Choosing some lovely font sizes and colours is a nice gentle way to
finish off an otherwise stressfull afternoon of building a CSS
website.

EMBED

88.

daveschaub 1:49 am on June 29, 2009

There are two properties that allow you to automatically set the
capitalisation of your text. First, font-variant allows you to set all
your characters in small versions of capital letters.
p {font-variant: small-caps; }
That would create text like this. It looks cool, and works well for
acronyms, like NATO. The second property is text-transform.
div {text-transform: uppercase; }

EMBED
89.

lauras2009 2:30 am on July 03, 2009

Can someone please explain why, in the “complex example”, the
multiplier is usually 16, 14, or 12, and in one instance it is 18?
e.g.,
font-size: 1.125em; /* 16x1.125=18px */
margin: 1.286em 0; /* 14x1.286=18px */
border-bottom:0.083em solid #ccc; /* 12x0.083=1px */
margin:1em 0; /* 18x1=18px */
??
Thank you

EMBED

90.

josiahsprague 8:40 pm on October 13, 2010

I’ve used the principles in this article as my best-practices for
years. However, my company just stopped supporting IE6 last
year and we are now revisiting our best practices for sizing text.
Since most browsers now use page zooming, we’ve considered
switching to pixels to size our text, but our new concern is mobile
browsers. How well do mobile browsers handle different units?
 Which unit is best to use with mobile browsers in mind? I’ve
heard many say that Ems are still the best practice for mobile
devices, but I’ve noticed that iPhone 4 doesn’t seem to size the
complex example
http://www.alistapart.com/d/howtosizetextincss/complexexampl
e.html from this article correctly. Is it better to use pixels for
mobile?

EMBED

91.

Holistic Practitioner 9:36 pm on October 19, 2010

Most of the wordpress themes that I have encountered do have a
widget or plugin to allow visitors to change the text size, as it is
sometimes too small from default, and messing with the CSS can
be a pain at times.

EMBED

92.

Seang 7:50 pm on March 31, 2011

Thank you for the article and your effort.
 I just thought I would offer comments now that it is almost 4
years old, and surely out of date. It seems like this article
advocates acrobatics of web design with ems, percentages etc,
when, to me, if you can’t read something you magnify it with
glasses or the equivalent, zoom, on your browser. Magnifying the
text and images (line height etc) keeps their context and their
visual relationship constant - a good thing. advocating the ability
to resize the text while keeping other things like images constant
is a misguided idea because when increasing text size eventually
the relationship of text to images gets uglier and nonsensical. If
there is a need to magnify text, wouldn’t it also help a visually
impaired type to magnify the images, too - bring them into focus?
In addition, I agree with the unpopular Brad Kemper - good
typographic practice is to add less than a line between paragraphs
- I prefer 1/2 a line. I am not a coder giving my typographic
opinion, but someone who has lived and breathed typography for
many years and has been recognized for skill in typography. I am
not too familiar with the author’s concept of vertical rhythm, but
vertical rhythm should not be slavishly adhering to a baseline grid
- that would be a monotonous rhythm - not to interesting and
rather mechanical.

EMBED

93.

Brett Jankord 1:38 pm on January 03, 2012

I’m with Josiah in that I too, am curious which unit is best to use
with mobile browsers in mind?
http://www.alistapart.com/comments/howtosizetextincss/P80/#
90
It would be nice to get an update to this article with mobile
devices in mind. I’d be curious if EMs are still the best solution, or
if something like REMs with an appropriate fallback or pixels is
 preferred now. Pixels seemed to have gain a lot of popularity for
sizing fonts.
I know in jQuery Mobile they use pixels for font sizes and also in
the HTML5 Mobile Boilerplate:
body { margin: 0; font-size: 13px; line-height: 1.231; }
Yet knowing a pixel is no longer a pixel on some new devices like
the iPhone4, it makes me think pixels aren’t the correct solution
to sizing fonts on these newer mobile devices where the pixel ratio
isn’t 1:1. I havn’t done any testing on font-sizing on mobiles yet
but I would think EMs or REMs with an appropriate fallback will
be the best solution for mobile?

EMBED

94.

John Amy 12:09 pm on March 12, 2012

Just picked up an old book of mine called Bulletproof Web
Design. It suggests setting the body font size as a Keyword….
small… and percentages to stray form the base. eg h1, 150%
This seems rather a good idea than having all that crazy em
mathematics. What do you guys think?

EMBED
95.

violetk 10:07 pm on April 16, 2012

If this is ever updated please include more sample calculations.
Font size ems seems to be easy to figure out, but the line heights -
especially when the font is larger than 18 pixels is giving me a
headache LOL. Similar to @lauras2009 question above.
It’s also not clear to me why this was updated away from the
62.5% rule, when that kicked out such lovely round numbers and
made the maths so much easier.

EMBED

96.

Professional Web Design

Company 10:31 am on July 30, 2012
Richard thank you for presenting this info so clearly. This is
another element in a developer’s bag of tricks to help create
responsive web design.

EMBED

1. Got something to say?

 Sign in to add your voice to the discussion.

Email (Need an account?)

Password (Forgot it?)
Don't put anything here

More from ALA

Order Out of Chaos: Patterns of Organization
for Writing on the Job
by Richard Rabil, Jr.
Your writing’s meaning isn’t only the the words. Foundational
patterns of organization can help you convey what you mean to
say.
· July 5, 2018
Writing

Your Emails (and Recipients) Deserve Better

Context
by Garrett Dimon
Email sender, subject, preheader—small elements, but they’re the
first seen and pack a huge punch. Always handle with care!
· June 28, 2018
Content

Discovery on a Budget: Part III

by Meg Dickey-Kurdziolek
Big value user research doesn’t need big pots of resource, just
clear process, well-directed focus, and care with data analysis.
· June 21, 2018
User Research

The Problem with Patterns

 by Cathy Dutton
As products and services move online, dependence on component
libraries can create a pattern of missing the forest for the trees.
· June 14, 2018
Design

Orchestrating Experiences
by Chris Risdon, Patrick Quattlebaum
In this excerpt from Orchestrating Experiences, you’ll learn about
weaving touchpoints together into a seamless experience.
· June 7, 2018
User Experience

The Cult of the Complex

by Jeffrey Zeldman
ALA’s Zeldman bemoans our industry’s fetish for the needlessly
complicated over the straightforward.
Code · May 31, 2018
or people who make websites.

 About

 Authors

 Masthead

 Style Guide
 Contact

 Sponsorships

 Follow us: RSS · Email · Facebook · Google+ · Twitter

A BOOK APART
Brief books for people who design, write, and code.
Bundle books and save!
Shop now

AN EVENT APART
Three days of design, code, and content for people who make websites.
See this year’s schedule

 ISSN 1534-0295 · Copyright © 1998–2018 A List Apart & Our

AuthorsPermissions & Copyright · Privacy Policy · Fonts
by Webtype · Log In · Register
 A List Apart An Event Apart A Book Apart Arcustech