Terrence Wood Posted…

From memory, IE/Mac 5 on OS 9 defaults to 96 dpi, and the font size can be increased or decreased via the keyboard. So for OS 9 users the only browsers that may have issues are NN4, IE4, and any of those other browsers I am sure nobody uses.

The best method for consistent cross platform font sizing I have found is to set the body to 75% (96dpi*0.75=72dpi and 16px*0.75=12px), and using ems for everything else.

The only cascade issue I'm aware of is IE/PC 5 with a HTML 4 transition doctype not cascading the font size through tables properly.

I fix this with:
* html th, * html td{ // deliver rule to IE only
font-size: 75%; // for IE5
fon\t-size: inherit; //for IE6
}

Patrick Griffiths Posted…

Ems are definitely the way to go in defining font sizes. They don't really have any cascading 'problems', they just work differently than pixels as you have to think about the font size of parent elements.

There's quite a lot more justification for using ems from Owen Briggs and myself.

liorean Posted…

Terrence: I kinda count ie5m as a one of those "modern Mac browsers", in the same way I count the OS 9 compatible moz versions in the same category, and all OS X browsers. They have one problem, though: They retain the 96 DPI even though the system may be set to a higher DPI. So, these browsers actually introduce an accessibility problem on such systems.

blakems Posted…

Sometimes the only way to get the effect you want is to use pixels, like for a line or border. Also shouldn't we consider that pixels is the unit intended for the computers and we should try use that, keeping in mind what may come in the future.

ant Posted…

Don't forget the sizes of the 2 camps: Classic Mac users vs. Visually-challenged users. Almost everyone will join the second group at some point in their lives. It's already a very large group, much larger I'll bet than Classic Mac users. Maybe we should think of Classic Mac users like Netscape 4 users - give them access, but don't bend over backwards for them.

liorean Posted…

Ant: Yeah, that's the way I'm starting to think of them too. Especially since both moz versions up to 1.2.1 and ie5m override the system and use 96DPI.

blakems: I was talking about font sizes. Font size should not be relative to screen size or set for easy computing, they should be set for usability and accessibility. Relative sizes are best, but if you really want an absolute size, you are better off with points than pixels. For sizing and positioning, though, screen, viewport or document relative sizes may be better, but that does also depend on purpose.

Tim Connor Posted…

Patrick, ems can have "cascading problems" dealing with dynamic content and CMS, depending on the layout. With manually generated content, or sufficient caution, you're right.

I built a CMS'ed site using entirely ems once that was a nightmare.

Richard Rutter Posted…

The 'cascading problems' with ems mentioned here and elsewhere are not problems (as in bugs or limitations) as such; they are just difficulties. With a little practice these can be easily overcome.

The main issue encountered is what I call 'inherited shrinkage' and is all to do with the 'cascading' bit of CSS. For example, one may wish to display list items and paragraphs the same size using a rule such as:

LI, P {font-size:0.75em}

This will work fine until your mark-up places a paragraph inside a list item, in which case the paragraph will be displayed much too small (at 0.75×0.75 = 0.5625 ems). A similar problem would be encountered with nested lists.

A simple set of rules at the end of your style sheet can overcome this using a descendant selector to keep the text size the same as its parent:

LI P, LI LI {font-size:1em}

A very handy tool for debugging inherited shrinkage and other cascading text size difficulties is Pixy's List computed (cascaded) styles favelet which enables one to type in the name of a CSS property (such as font-size), move a cursor over the active document and see the cascaded elements and the computed value of the property for each.

Jim Dabell Posted…

Font size issues with ems usually go away once you realise what you are doing. The example given of <p> elements inside lists is a perfect example. You need to ask yourself why you are changing the font size. I find that it's almost always because it's inside a particular part of the page, rather than a specific element. So select that part of the page with a #navigation or #content selector rather than trying to modify each and every element within it. Font size is inherited, so you don't have to worry about the elements within that section of the page.

Bruce Posted…

Yes, pixels hurt accessibility, but points is not the satisfying answer always. If you build a dhtml popup menu with javascript, you will see that you should use pixels. Points make script code more complex and open for compatibility problems.

Edwin van Vliet Posted…

I think you got it wrong. It's a definition thing. 1pt is defined to be about 1/72". How do you know the size of the computer screen in inches? I think you can't know. Imagine a computer screen of say 800" diagonal. If you define the font to be 12pt, then your text will be about 1/6" high according to the definition. That's rather small.

Why not use a truly relative font size as em or percentages? They are quite perfect if you don't know the size of the medium. It's up to the user to set his screen font size to his own taste or needs. If you don't adjust the base font size too dramatically (keep it between 75% and 125%) the user should be able to read the page. If he uses insane settings, it's not up to a developer to try to fix that.

Note that the software settings of 72 and 96dpi are quite odd anyway, if you keep the definition in mind. The software does not know if I use a 15" or 20" screen, remember?

ronny Posted…