The CSS Text Size Conundrum

Jump to navigation (9)

August 15, 2002 — Written only three months ago, this article is already quite outdated. The current version of this site makes extensive use of relative font sizes in percentages, in a style sheet which is then hidden from older browsers which could possibly mess it up. This was our standards compliant solution to the problem.

February 10, 2004 — To my utter amazement, this topic is still of major concern to Web developers today. Check out this forum thread.

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 1em equals 100% (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. If you use them, you may want to do a browser detection JavaScript, 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 resize anything).

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.

The latest Opera browsers have a cool function: you can make it identify itself in JavaScript as Mozilla (Netscape) 3, 4.78 or 5 (which is called Netscape 6), IE 5 or Opera. But this may cause you problems if you use the browser detection method for linking to style sheets. Netscape 4 requires lower em numbers or percentages than the other browsers, to produce the same text sizes; therefore, an Opera browser set to identify itself as Mozilla 4.78 or similar, would get smaller text using this method.

Another problem with em’s or percentages, occurs with nesting styles. If you are inside a table cell that’s styled with text size at .8em or 80%, then you use a <p> tag that’s styled with text size at .8em or 80%, 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:

Pros and cons of seven possible solutions

Forget CSS altogether, and use plain old HTML font tags.
Pros: Text is resizeable. Everyone can print it. Looks OK if CSS fails. May be a reasonable solution, if you keep it to a few <small>, <big> or <font size="-1"> tags, and nothing more.	Cons: Many Macs will display smaller print than intended. Few size choices. Can result in a clutter of <font> tags and longer pages. Difficult to change font for the entire site. Not “forward thinking”. Font tags are already deprecated and may be phased out in years to come.
Don’t size anything in CSS. Use small headings like <h5> for small print, and specify font-weight: normal; in the style sheet.
Pros: Text is resizeable. Everyone can print it. No cluttered HTML to maintain.	Cons: Many Macs will display smaller print than intended. Few size choices. Small, bold print will look funny on browsers like Netscape 3 that don’t support CSS. We’re stretching the envelope here; this isn’t the intended use of <h5>.
Use CSS keywords and the workaround mentioned above. Watch your DTDs, and test thoroughly.
Pros: Text is resizeable. Everyone can print it. No cluttered HTML to maintain. No nesting problems. “Small” is always small.	Cons: Netscape 4 interprets keywords oddly. Hide the keywords from Netscape 4 by using @import url. Many Macs will display smaller print than intended. Few size choices. Opera has quirky support for @import url; my link properties and text sizes both messed up when I tried using it.
Use CSS relative keywords—“smaller” and “larger”.
Pros: Text is resizeable. Everyone can print it. No cluttered HTML to maintain.	Cons: Few size choices. How much smaller or larger varies with the browser. Netscape 4 (Mac) and IE 3 will ignore them. Weirdness may result when text is resized in IE.
Use CSS em’s or percentages; if you like, add a browser detection JavaScript or an “imported” style sheet.
Pros: Text is resizeable. Everyone can print it. No cluttered HTML to maintain. Good choice of sizes. Custom sizes for various browsers are possible with the JavaScript.	Cons: Nesting styled elements may cause compounding of sizes, with weird results. If a user has resized the text in his browser, your site will not look as intended. Some earlier browsers don’t support em’s or percentages properly and will ignore them altogether or treat them as pixels. Opera users will still get the wrong size, if their browser is set to identify itself as Mozilla (Netscape) 4.78 or similar. The @import thing can be tricky; even newer browsers each tend to support it differently. Using even a simple JavaScript to choose a style sheet, seemed to slow down page loading significantly, when I tested it.
Use CSS pixels for all sizes.
Pros: No cluttered HTML to maintain. Good choice of sizes. One size fits all: text will render nearly identical across browsers and platforms. This may be the only way to ensure a rigid design. Nesting of styled elements is not a problem. Opera, Netscape 6, and IE 5 (Mac) can still resize the text. For most modern printers, printing is no problem.	Cons: Text is not resizeable, except in Opera, Netscape 6, or IE 5 (Mac). Some printers may print 16px text as 16 dots high, and if it’s a 1200 dpi printer, you’ve got microscopic print. Not many items here, but very important ones for accessibility. Is a pretty but rigid Web page design worth these problems?
Don’t size anything! Let paragraphs, headings and lists all display at default sizes.
Pros: Text is resizeable. Everyone can print it. No cluttered HTML to maintain.	Cons: You’re at the mercy of the browser, the platform and the user’s preferences, in regard to what your text will look like. Basic HTML limits size choices to normal text and headings.

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 .83em, or 83%, or 10px, to ensure legibility across browsers and platforms. If you’re using JavaScript or another method to serve up different style sheets for different browsers, still keep the 10px practical limit in mind. Most fonts look awful at 9px and 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.

  Exceptions:

  • 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 went to percentages next, using a JavaScript to provide a different style sheet (with lower percentages) for Netscape 4 Windows only. The JavaScript slowed down the page load. I also tried the @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 just fine.

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 h1 headings on the Zelda site were left in 48px size. 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.