November 2003
-
28 » Size matters
First of all, let me apologize for not posting more frequently. I have been working on various projects recently, and I had to shift my attention to my business site for a while. To make it up to you, this entry will be a lengthy one, because size matters.
An interesting discussion has been taking place over on Dave Shea's Mezzoblue on the subject of font sizes in web design. In fact, there are basically two disussions taking place. The first is about what constitutes a good size for text, and the other is about how to actually set that size in the first place.
Long-time readers may remember I talked about this before:
- 03/24/03 - Microscopic text is everywhere
- 03/25/03 - More on tiny text
- 03/28/03 - Typographic Truce
My position has not really changed, and that can be seen in the websites I produce. The most important component of any website is its content. If the content is hard to access, users will be turned away. Body text constitutes the bulk of a website's content, and for this reason I make sure that body text is set to a reasonable size.
So what is a reasonable size? I would argue that it should be set by the browser default. Naturally, this varies from system to system, but in most cases it can be changed by the user in the browser's menu, or even at the system level. Why do I think we must do this? Because we know almost nothing about our user:
- Don't know what system they are on (PC, Mac, cellphone, etc.)
- Don't know what user agent they are using (Internet Explorer, Mozilla, small-screen Opera, etc.)
- Don't know what screen size they have (or even if it is a screen)
- Don't know what resolution they are running at
- Don't know what their system settings are
- Don't know what their browser font settings are
- Don't know if they are using a user-created style sheet
- Don't know if the user knows how to change any of their settings
There a probably more things to consider besides these. For example, a screen-rendered font is usually easier to read if it is display in black on white, rather than the inverse of this. In fact, white text on a black background can often appear smaller. Naturally, the choice of typeface will make a significant difference to the readability of text as well.
On this website, I set the body text to display in Georgia at 100%, which I believe to be easy for most to read. Here are some alternatives, listed in descending order according to the size and unit. I have matched the em and px values according to how they appear on my WinXP/IE6 combination, with everything else set to default:
- 1.2em
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 19px
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 1.1em
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 18px
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 1.0em
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 16px
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 0.9em
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 14px
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 0.8em
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 13px
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 0.7em
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 11px
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 0.6em
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
- 10px
- Georgia, 'Times New Roman', Times, serif
- 'Times New Roman', Times, serif
- Verdana, Arial, Helvetica, sans-serif
- Arial, Helvetica, sans-serif
When viewing Dave's Mezzoblue site, body text is appearing as 0.8em Verdana to me, with everything else being smaller. Although the body text is perfectly readable, I regard the navigation text to be far too small - and this appears to be typical on sites created by Mac-happy visual designers. I think Dave should bump everything up a size, in fact
font-size: largerwould probably do the trick.So I always try to do the following:
- Choose one of the two most readable screen fonts, Georgia or Verdana
- Put a CSS rule in the
bodythat sets the font size to 100% - Have my body text at 1em, less important stuff at 0.8em
By following these rules, I have found the appearance of text to be reasonably consistent across system/OS/agent combinations. Since I prefer to use a combination of rules-based design and fluid, scalable layouts (instead of grid-based, fixed layouts), the discipline works well. Nobody has told me that the text on my websites is "too large" as of writing, and that may be because the Georgia font I prefer looks good at the browser default size. I agree that Verdana looks a little ugly at the same size, but I find I use that font for navigation; therefore, I only use it at 0.8em.
Arguments over font sizes will always exist, as long as systems vary so much. Trying to fix the appearance of a site is no longer wise in this world of varying user agents, and content should always be easy to read.
-
14 » Don't jump the Q
Another update to the article on serving up XHTML. With the help of Bill Mason, I have managed to refine the technique to respect the existence of quality ratings in the
Acceptheader. As before, feedback is appreciated. I found it difficult to expand the logic to includeqwithout increasing the difficulty level of the article in general. I was forced to gloss over the actual test to avoid getting into details about pattern matching. I may take another look at it over the coming weekend. -
03 » Vary
I had an interesting email from Jim Dabell on Saturday, in reference to the article I wrote on how to serve up XHTML with the correct MIME type. He first pointed out that the table of MIME types was misleading, and I have since updated it. He also mentions that the content negotiation technique is flawed in two respects:
- Because content is varied based on the header supplied by the client, the header sent back to it should include a
Varyheader to indicate this, or risk confusing proxies and public caches. - Searching for a string containing
application/xhtml+xmlin theAcceptheader is not in itself sufficient to determine whether or not the user agent should be served with that type, because theqweighting is ignored (q= quality, apparently).
Sadly, we are now entering a realm of the Internet of which I know absolutely nothing. I am therefore at the mercy of Google to figure out what I am supposed to do. After digging around a bit, I discovered the utterly incomprehensible HTTP specification (mercifully in HTML, rather than plain text) and learned a little bit about both issues.
With my newfound knowledge, I have updated the article to include mention (and implementation) of the
Varyheader, with it set toVary: Accept. I am not 100% certain if this is the correct setting, and I would appreciate feedback on the matter.Trying to deal with the
qweighting is another matter entirely. I am not sure what to do about it yet, so I am going to give it some thought over the next few days. Once again, feedback would be grately appreciated. - Because content is varied based on the header supplied by the client, the header sent back to it should include a