You’ve just finished creating your new home page, and you’ve even made a style sheet. The page text is formatted in 13-point Verdana—just large enough to make the print “thick”, so it’s readable against your background image. At the bottom of the page is a disclaimer, in fine print (7-point Verdana), in a little white box.
All excited, you phone your neighbor and tell him all about it. He finds your page on the Internet and says, “Boy, I can hardly read this.” “What?!?” you exclaim. You hang up the phone and dash across the street to see what’s wrong. Oh, by the way, your neighbor has Netscape 4.76.
Horrors! The page text is thin and hard to read against the page background. And what’s worse: the disclaimer is now so tiny that it’s impossible to read! What has happened?
The answer is simple: you have fallen victim to the old “cross compatibility bug”—what looks fine on Internet Explorer may look awful on another browser. What’s worse: the lady down the block pulls up your page on her Mac, and the text is even smaller! What can you do to fix this problem?
I asked myself this question, and then I literally spent weeks pondering possible solutions. I probably thought of some that no one else ever did! But let me share with you some of the things I learned, as well as which solution I chose, and why.
First of all, CSS allows you to use a variety of units for defining font sizes (and sizes of just about anything, for that matter). Text may be sized in points, pixels, picas, inches, centimeters, millimeters, em’s, ex’s, percentages or by using keywords (small, x-small, xx-small, medium, large, x-large or xx-large). Most of these don’t work very well.
Inches, centimeters and millimeters are not commonly used. I’ve messed with them a little bit myself, with widely varied results. Oddly, text sized in these units can be resized in the Netscape browsers but not in Internet Explorer.
A pica is equal to 12 points and is seldom used in CSS. Points work well for the printer, but the Mac platform defines them equal to pixels in many cases, resulting in smaller print than Windows produces. Newer browsers (IE 5 and Netscape 6) for the Mac, correct this problem, emulating Windows’ behavior. So it’s all mixed up.
Keywords may be a limited solution. Todd Fahrner, in an article entitled Size Matters, describes a workaround which will trick IE 4 and 5 for Windows, into using the keywords the same way that other browsers do. I tried it, and on IE 6, it works only with certain DTDs (doctype declarations) at the top of the HTML document. The workaround does not apply for this browser, and its interpretation of CSS keywords depends upon the DTD. If you use the wrong DTD, the text will appear one size smaller than intended in IE 6, regardless of the workaround. See Microsoft’s page on IE 6 and doctype for the details as to which DTDs will put IE 6 into standards-compliant mode.
An article at Webmonkey by Steve Mulder, entitled Sizing Up the Browsers, includes a series of tables which give the proper values to use in various units, to produce the same size text. The values he gives for keywords don’t hold up on my computer, with my various browsers, and the mess gets worse when I change the doctype.
Relative keywords are another option. There are only two of them, “smaller” and “larger”. I’ve tried them, and they do work, but how much smaller or larger varies with the browser. Netscape 4 (Mac) and IE 3 will ignore them. Also, they resize oddly in Internet Explorer (as do em’s and ex’s; see below), and when you do resize them, the links may act funny on hover. Anyway, with only those two choices, you don’t have much control over text sizes.
Pixels will give nearly the same, if not identical, results across all browsers and platforms. Another article, Give Me Pixels or Give Me Death by Jeffrey Zeldman, made an excellent case for either using pixels or not sizing anything at all (the article has been removed from their site because it is now outdated).
The bad news is that some (especially older) printers will read the pixels as dots, and print the text so tiny that it isn’t readable. More bad news: only IE 5 (Mac), Opera and Netscape 6 (both platforms) can resize your text in the browser. This means that if someone needs larger print due to poor eyesight, they won’t be able to get it in most cases.
Ex’s are ignored by Netscape 4 (Mac). Netscape 4 (Windows) uses a funny algorithm that yields unpredictable results.
That leaves only em’s or percentages, which are nearly
interchangeable, if you assume
(I noticed a slight difference in some cases). Em is the unit
recommended by the W3C
(World Wide Web Consortium). The problem is that em’s
don’t yield the same size across browsers and platforms.
to choose the right style sheet for whatever browser your visitor
is using. Then you can match the sizes (assuming that your visitor
has everything set to default values). Text sizes in em’s
will print well and are resizeable in most browsers (AOL and MSN Explorer 6 can’t
Internet Explorer (Windows) is quirky about resizing these units. Text sized in ex’s or em’s (or by relative keywords), will resize by huge increments. Selecting “smaller” will put the text in a very small but readable size; “smallest” will make it illegible; similarly, “larger” makes it huge, while “largest” makes it ridiculously large. However, if you size the text by percentages, Internet Explorer will resize it in smaller increments, giving the user better control.
Jeffrey Zeldman, in the article cited above,
reports that Netscape 4 (Mac) ignores em units altogether.
It will render percentages when used for line-height but ignore
them altogether when used for font-size. And some versions of
Netscape 4 for Windows treat percentages as pixels (I have three
versions of Netscape 4 for Windows: 4.03, 4.51 and 4.77. I have
never encountered this problem with percentages on those versions,
so I assume that it’s rare).
IE 3 doesn’t
recognize em’s and will render the text in pixels,
making your giant
3em heading as 3 pixels tall,
literally too small to read! Be sure to hide these units from
these browsers to ensure accessibility for all users.
Another problem with em’s or percentages, occurs with nesting
styles. If you are inside a table cell that’s styled with text
80%, then you use a
tag that’s styled with text size at
the system may multiply the two and give you smaller text than you
intended. Be careful about nesting styled elements when using
em’s or percentages.
Possible working solutions:
|Forget CSS altogether, and use plain old HTML font tags.|
Don’t size anything in CSS.|
Use small headings like
Use CSS keywords and the workaround mentioned above.|
Watch your DTDs, and test thoroughly.
|Use CSS relative keywords—“smaller” and “larger”.|
|Use CSS pixels for all sizes.|
|Don’t size anything! Let paragraphs, headings and lists all display at default sizes.|
Finding the Right Solution, and Making It Work
Obviously, while each possible solution to the “CSS Text Size Conundrum” has its advantages and disadvantages, and some solutions may be better than others, there is no clear cut solution to the problem! And there won’t be until there is better browser support for CSS, and until most everyone is upgraded to it (if you think text sizing is a mess, try doing page layout in CSS!).
(Update: this page is laid out in CSS now; this has occurred since this article was written.)
Below are some final thoughts, including which solution I chose for The Oo Kingdom:
Keep it accessible. Which is more important: a perfectly laid out Web page, or one that everyone can read and print? The latter, of course! But not everyone seems to believe that. There’s a multitude of Web portals out there that have crowded home pages full of teeny, tiny text that can’t be resized. Surf your IE 4 or higher browser to msn.com and try selecting View > Text Size > Largest. You’ll see what I mean.
Keep it legible. Ideally, even your fine print should be no smaller than
10pxpractical limit in mind. Most fonts look awful at
9pxand are difficult to read.
Keep it consistent. If you size some of your text in pixels and the rest in em’s, percentages or not at all (as I have done in the past), your sizes will vary tremendously across browsers and platforms, to the point of looking comical! If you use pixels, size all of your text in pixels. If you use em’s or percentages, use them for all of your text.
- You can get away with not sizing some elements and sizing others in em’s or percentages, if you don’t mind Netscape 4 getting a slightly larger font than intended for the sized elements.
- Large headings may be OK in pixels.
My first conclusion for the Oo Kingdom was to take the easy way
out and do pixels, being sure to keep even the “fine print”
large enough so that most people would have no trouble reading it.
While this may be good enough for most people, I wanted more! So I
style sheet (with lower percentages) for Netscape 4 Windows only.
@import url thing and had poor luck with it;
even when I followed the directions to the letter, Opera 6 and
Netscape 6 gave me the wrong size text, and Opera 6 also fouled up
my link properties! By the way, Internet Explorer 6 handled it
So what did I do? I chose different fonts (with the help of Wendi and Joe) that work well in default sizes. I didn’t have to size anything! It works perfectly, and the site loads quickly. Anyone can resize the text as needed, and the pages don’t fall apart.
Regarding the satellite sites:
I kept a few percentages on Joe’s Pokémon and Digimon sites,
and Wendi’s craft site. The oversized
headings on the Zelda site were left in
Everything else is unsized.
I guess when it comes to Web design, simpler is better. After all, the Web is about information, not presentation. This approach is discussed in detail by John Allsopp in his article, A Dao of Web Design, at A List Apart. A lot of webmasters need to read that article… and take it to heart.
This Page is Quoted Across the Internet
A brief quote from this page appears on an excellent Web page written for professional website builders by Jim Byrne in March 2003, entitled The MCU: Accessible Web Design Consultancy: Accessible Web Text - Sizing Up The Issues. The same article also appears at devwebpro.com.