Font sizes

What do you do?

[ssih]

I'd like to ask what you folks do about font sizes. A few years ago, I did a website for a state organization that dealt with accessibility issues of the physically and mentally challenged. One thing that was paramount in the design of their website was that there could be no hard font sizes. Font sizes had to be relative sizes ("large", "smaller", etc.). I've tried to keep to that standard when designing my business sites, but it's not often easy, and the results aren't usually satisfactory. "small" on Netscape is very different from "small" on IE.

I've looked at the code on sites created by highly respected website designers and I see a lot of "font-size: 12px" and "font-size: 1.2em", etc. Have I been led astray by this need to keep to relative sizes? Life would be so much easier if I could just pick a hard size that would look like I want it to on ALL browsers.

[ssih]

em & ex break disasterously in IE3.0

I checked two of my sites' logs. One shows 0.5% of the visitors are using IE3.x. The other shows 0.04%. What specifically goes wrong on this browser using em, and how badly will it affect this very small percentage of users?

[papabaer]

Isn't the <font> tag depreciated?

Depreciated AND deprecated! ;)

There is no single correct answer. What works best is determined by application. The ALA site for example freely "mixes 'n matches" using both .px and .em units of length. The W3C CSS2 page employs .em and % (percentage) for font-size management. To best understand the pros and cons, a better understanding of the units of measure is needed (see W3C CSS2 Specifications Section 4 CSS2 syntax and basic data types: 4.3.2 Lengths). [w3.org...]

There are two types of length units: relative and absolute. Relative length units specify a length relative to another length property. Style sheets that use relative units will more easily scale from one medium to another (e.g., from a computer display to a laser printer). - W3C

Relative units are:

• em: the 'font-size' of the relevant font
  
• ex: the 'x-height' of the relevant font
  
• px: pixels, relative to the viewing device
  

The .em unit can be troublesome, though theoretically it is ideal. Read the following quote from the W3C specs and note the potential pitfalls:

The 'em' unit is equal to the computed value of the 'font-size' property of the element on which it is used. The exception is when 'em' occurs in the value of the 'font-size' property itself, in which case it refers to the font size of the parent element. It may be used for vertical or horizontal measurement. (This unit is also sometimes called the quad-width in typographic texts.)

BAD JOKE ALERT! What did one .em say to the other .em? Who's your Daddy?

Wince all you like now, but hold it to heart when you venture into the realm of .em's! Used correctly, the .em is an ideal font-size unit of measure.

Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0227 degrees.

Pixel units are relative to the resolution of the viewing device...

With this in mind, .px may be the portable unit of measure across devices.

Absolute length units are only useful when the physical properties of the output medium are known.

The absolute units are:

• in: inches -- 1 inch is equal to 2.54 centimeters.
  
• cm: centimeters
  
• mm: millimeters
  
• pt: points -- the points used by CSS2 are equal to 1/72th of an inch.
  
• pc: picas -- 1 pica is equal to 12 points.
  

In cases where the specified length cannot be supported, user agents must approximate it in the actual value. <--- be VERY afraid!

Ideally? The very best unit of measure is NONE AT ALL! Let the user-agent determine the display according to the user's preference - BUT! We also know that with most designs, this is not a very practical approach.

Personally? I prefer the "mix 'n match" flexiblilty of .em and .px - As user-agents become more "user-friendly" desinger sizing will NOT be as potentially problematic OR controversial as it stands now. ;)

- papabaer

<font> Bad!
CSS Good!

[ciml]

ssih, the problem is that when IE 3.0 encounters units of which it is unaware (eg. em) it incorrectly treats them as px. So rather than a 2em heading being twice the default font size, it is presented at 2 pixels high. There are only a few IE3.0 users now, but I think that we should continue to remind ourselves of the vendors who spoiled the CSS promise of a beautiful and accessible Web. It wasn't only Netscape.

papabaer:
> With this in mind, .px may be the portable unit of measure across devices.

Yes, but not across across preferences or the limitations of the viewing equipment (human eyesight). If the text is rendered on a passing cloud for viewing at one mile distance then it should be just as easy to read as on a 14" screen at one foot distance, because it's scaled up. On the other hand, if a user specifies large default text due to eyesight problems, then units relative to default size are much kinder.

Of course for most intents and purposes Web browsers and Web documents are broken in these regards. The advantages of CSS units are unlikely to be realised, so their merits are largely academic. As a result, the Web of the future will in many cases cope with us if we continue to make the mistakes of the past. :(

[papabaer]

Ciml, I agree. We are dealing with another version of "browser wars." The latest version however is based on features, not propriety code.

While Opera (ZOOM) and Mozilla/NS6/7 allow for user-preference text-resizing of .px, IE does not... yet. Once again, I'll repeat tha obvious: IE6 is in need of a major overhall. M$ cannot refuse to allow the extensive features offered by Opera and Mozilla/NS go unanswered. This includes increased accessibility functions such as full ZOOM (Mozilla & NS lag here too) and additional user preference controls.

Regarding .em and older browsers such as IE3 that misinterpret this unit of measure. Once again the @import rule saves the day!

IE3 does not understand the @import rule and will render all CSS controlled content using browser defaults. As long as logical page structure and proper use of HTML/XHTML elements are used, the resulting display will be one the even Jakob N. would approve.

<style type="text/css">
@import "protect-from-old-browsers.css";
</style>

You gotta luv it! :)
- papabaer

[rewboss]

I'm amazed at that...I've never once had a complaint about the visibility of a proportional font size...and I'm currently running a site that has at least five thousand visitors a day...I've previously worked on higher traffic sites

were you using proportions lower than 100%?...surely that's the only reason it might happen...otherwise you are using the visitor's default font size...unless the very first thing they do on getting the computer is to visit your site I would hardly expect them to be blaming it

One or two of them sent screenshots. I'm not sure if I still have any of them, but anyway it was proof positive that they weren't kidding.

I started with .7em. Why? Well, I don't know about you, but I think that Verdana at 100% size looks ugly. It took an awful lot of careful coding to make sure I didn't nest anything with .7em size inside anything else with .7em size (thanks to the way page elements in NS4 only sometimes fail to inherit from the body element, so you have to work around that).

A bunch of Mac users complained.

Then I switched to 70% instead. The Mac users fell silent, but then (beyond all expectations) a bunch of Windows users complained. Yes, it was a particular constellation of browser and platform, but it turned out to be more common than I thought. In fixing that one, I made a mess of it for NS4 users. At the time, 20% of my hits were from NS4.

Conclusion: Sometimes, no matter how noble a principle is, you have to remember that we live in the real world. Also, you have to bear in mind that about 99.9% of your visitors don't bother to complain. I test my sites by posting the URL on a bulletin board not populated by web designers and saying, "OK, folks, break this if you can." I've found it's the only way to get reliable feedback, because it's a more representative cross-section of the internet community -- the people who don't update their browsers and don't upgrade their operating systems every six months.

[Crescendo]

Rewboss: much better to resize and reflow the text than zoom in and introduce horizontal scroll.

Having used Opera's Zoom feature, I have to disagree. Since it resizes images as well, the page layout remains intact. I just tried my work site in Mozilla and upped the text size. Lines of text started overlapping and the page looked a right mess.

[Mark_A]

Just to add my 2p worth.

What I find irritating about css is that there appears no support for simulating 1 2 -1 -2 etc font sizes which were often used in page html based font sizing.

So if trying to change a working site to css you have to pick an approximation and none of them work the same as that which is a right royal pain in the proverbial.

I thought css was supposed to make things easier.. perhaps on new sites but on old ones trying to upgrade slowly no way.