Typeface selection in CSS

[Andy Dingley]

Hypothesis:
There are two, and only two, appropriate ways to do this in CSS.

font-family: serif;

font-family: sans-serif;

Discuss.



Systems (with font capability) may be expected to implement these rules
correctly, with some locally-appropriate choice of default font. Without
knowing names of local fonts, there's barely any more possible choice
than this.

There are a set of fonts that are "likely" to be found on a useful
proportion of Windows systems. These are no improvement over the
defaults and aren't worth selecting.

Comic Sans is likely to be found and identifiable on a significant
number of systems. The reasons not to use it are aesthetic, not
technical.

There is no other way to select a font, given the vagaries of the set
locally installed. Fighting to choose Trebuchet over Verdana is of
negligible aesthetic benefit, causes more trouble with sizing
differences than it solves, and still ignores the non-Windows users.
Century Schoolbook may well be a better choice than Times Roman for
solid blocks of body text, but even that level of choice is rarely
workable.

Embedded fonts are problematic.

So as the only practical decision available to the web designer is
serifs or not, that's all they should attempt to choose. Leave the rest
to the local system and its defaults.

 

[Els]

Hypothesis:
There are two, and only two, appropriate ways to do this in CSS.

font-family: serif;

font-family: sans-serif;

Discuss.



Systems (with font capability) may be expected to implement these rules
correctly, with some locally-appropriate choice of default font. Without
knowing names of local fonts, there's barely any more possible choice
than this.

There are a set of fonts that are "likely" to be found on a useful
proportion of Windows systems. These are no improvement over the
defaults and aren't worth selecting.

Comic Sans is likely to be found and identifiable on a significant
number of systems. The reasons not to use it are aesthetic, not
technical.

There is no other way to select a font, given the vagaries of the set
locally installed. Fighting to choose Trebuchet over Verdana is of
negligible aesthetic benefit, causes more trouble with sizing
differences than it solves, and still ignores the non-Windows users.
Century Schoolbook may well be a better choice than Times Roman for
solid blocks of body text, but even that level of choice is rarely
workable.

Embedded fonts are problematic.

So as the only practical decision available to the web designer is
serifs or not, that's all they should attempt to choose. Leave the rest
to the local system and its defaults.

Is it enough to say "I disagree with the last paragraph", or should I
also use arguments to sustain my opinion?

 

[Toby Inkster]

There are two, and only two, appropriate ways to do this in CSS.
font-family: serif;
font-family: sans-serif;

What about "monospace"?

The naming of specific fonts in the "font-family" property won't work for
all of the people, all of the time, but the same can be said of:

* Javascript
* CSS
* Images
* Publishing on the WWW at all (plenty of people without access)
* The English Language[1]

Just use it wisely and provide a decent fall-back.

____
[1] Though it has been estimated that within 10 years, over half of the
world's population will speak English. (Obviously not as a first language
in most of the cases!)

 

[Luigi Donatello Asero]

Andy Dingley wrote:
____
[1] Though it has been estimated that within 10 years, over half of the
world's population will speak English. (Obviously not as a first language
in most of the cases!)

How many people will speak Chinese as first language in 10 years?

 

[Andy Dingley]

What about "monospace"?

Fair point - add monospace.

I skipped cursive because I'm not even sure if that has any reasonable
expectation of default support, beyond the simply illegible.

The naming of specific fonts in the "font-family" property won't work for
all of the people, all of the time, but the same can be said of:

The examples you cite have extensive value, and a quite reasonable
expectation of support. Even JavaScript is usually there, quite robust
if it is, and can add much value to a page. Requiring a page to be
minimally useful without it isn;t the same as saying it's so broken we
may as well not bother.

My point here is that the only choice you can make with any real
expectation of success is to suggest Trebuchet or Verdana as
alternatives to Arial, and have these accepted by most of the users.
However they add almost nothing to the page (they're poor fonts anyway,
and they're practically indistinguishable from Arial for most users).

 

[Toby Inkster]

How many people will speak Chinese as first language in 10 years?

At a guess, probably about 1.25 billion.

 

[Toby Inkster]

Fair point - add monospace.
I skipped cursive because I'm not even sure if that has any reasonable
expectation of default support, beyond the simply illegible.

And "fantasy", but does anyone really know what that's supposed to look
like?

The examples you cite have extensive value, and a quite reasonable
expectation of support. Even JavaScript is usually there, quite robust
if it is, and can add much value to a page.

According to Codestyle's survey, "Verdana" is installed on 94% of Windows
systems, 92% of Mac systems and 53% of Unix systems.

Assuming that 92% of all visitors are using Windows, 5% on Mac and 3% on
other UNIX-based operating systems, this gives us:
100% * ( (0.92*0.94) + (0.05*0.92) + (0.03*0.53) ) = 92.67%

So about 93% of people will notice if you use "font-family: Verdana". I
would class that as a "quite reasonable expectation of support".

 

[kchayka]

There are a set of fonts that are "likely" to be found on a useful
proportion of Windows systems. These are no improvement over the
defaults and aren't worth selecting.

Can we count Arial and Verdana in this list? I personally find Arial to
be one of the uglier fonts around, the reason for its ubiquitousness on
the web escapes me.

So as the only practical decision available to the web designer is
serifs or not, that's all they should attempt to choose. Leave the rest
to the local system and its defaults.

Amen to that. It is a pretty rare case where a specific font is actually
a better choice than a generic serif or sans-serif font. IMO

 

[Lauri Raittila]

Hypothesis:
There are two, and only two, appropriate ways to do this in CSS.

font-family: serif;

font-family: sans-serif;

Discuss.

First one is not good IMHO. Latter is worse than none, but not that much
(when user prefers something else - generic sans-serif is either verdana
or arial, neither of is very nice sans font for webbrowsing...).

serif is as bad as TNR - will screw up anyone that has selected Arial or
other similar sans font to be default, as it easily gets unreadable on
sizes sans fonts are still OK. (Sure 0.001% of people have adjusted serif
to something comparable, but some might use some nicer and even less
readable serif...)

Systems (with font capability) may be expected to implement these rules
correctly, with some locally-appropriate choice of default font. Without
knowing names of local fonts, there's barely any more possible choice
than this.

Not really. IIRC, IE4 and early IE5 had lots of problems with generic
font-families.

Comic Sans is likely to be found and identifiable on a significant
number of systems. The reasons not to use it are aesthetic, not
technical.

It is suitable for headings and stuff, just like almost any other font.

IMO, generic font family is just as bad as any other font family for body
text. It is practically always TNR or Arial anyway, and when not is more
something horrible than something better.

My conclusion:
1. for body text font, do absolute nothing
2. for headers, do what you want, as long as you don't use generic
families exept sans-serif...
3. for monospace, use appropiate HTML element, and don't use generic
monospace without good reason, it will use courier far too likely, which
is bad as courier is not always TTF...

 

[kchayka]

generic sans-serif is either verdana or arial,

Not in my browser, it isn't. And even if it were, it then makes no
difference between:

font-family: sans-serif;
and
font-family: Arial, sans-serif;

However, with the former, at least the user may get something better
than Arial.

1. for body text font, do absolute nothing

That is actually my first choice as well, except sometimes either serif
or sans-serif goes better with the overall design and/or logo.

 

[Andy Dingley]

So about 93% of people will notice if you use "font-family: Verdana". I
would class that as a "quite reasonable expectation of support".

Read my last paragraph.

It's likely to be supported, just not a useful font to choose.

 

[Alan J. Flavell]

According to Codestyle's survey, "Verdana" is installed on 94% of Windows
systems, 92% of Mac systems and 53% of Unix systems.

So the problem explored at
http://www.xs4all.nl/~sbpoley/webmatters/verdana.html
is even *more* prevalent than I assumed.

That gives us yet more reason *not* to specify Verdana in an author
stylesheet.

I'm sure it's a perfectly fine choice for an individual to make in the
privacy of their own browser, and at a size of their choosing (as long
as misguided authors don't go and overrule it...)

I'm talking basically about body text here, mind you.

 

[Toby Inkster]

That gives us yet more reason *not* to specify Verdana in an author
stylesheet.

Verdana, know your place!
http://tobyinkster.co.uk/web-fonts#verdana

 

[Spartanicus]

That gives us yet more reason *not* to specify Verdana in an author
stylesheet.

I'm sure it's a perfectly fine choice for an individual to make in the
privacy of their own browser, and at a size of their choosing

User setting: Verdana reduced in size by a factor Y.
Author setting: Verdana reduced in size by a factor Y.
Result: Verdana reduced in size by a factor 2xY = microfont.

The same thing but somewhat less drastic happens when using most other
sans serif fonts as the user font.

To avoid this, specifying a sans serif font as the user preferred font
should be accompanied with a browser minimum font size setting equal to
what the user wants to see as the body font size.

This in turn prevents non body text from being displayed at a reduced
size which results in losing the ability to de-emphasize text. For
example I like my body text displayed in Verdana @ 13px, but I can
comfortably read Verdana down to 10px. Due to the necessary minimum font
size setting of 13px I see content that has appropriately been sized
down at the bigger size of 13px. This makes it harder to distinguish
body text from for example side bar/panel content.

Many find TNR and most other serif fonts not pleasant to read on screen
@ the typical body text size. I'm sympathetic to authors who want to
suggest a sans serif font for their sites for the many users that don't
change the default font in their browsers. Some suggest that authors
should not do that and that they should instead show the user how to
change the font locally. This I consider bad advice, a IE user cannot
specify a minimum font size.

 

[Alan J. Flavell]

User setting: Verdana reduced in size by a factor Y.

Sorry, that doesn't rhyme. The user's choice is the user's choice.
It isn't "reduced" by anything. Sure: it's likely to be a smaller
choice than they would have made if they'd used some other font. But
it's still their choice.

Author setting: Verdana reduced in size by a factor Y.

User's defence: the minimum font size setting (in a good browser), or
the "ignore author font settings" in the operating system component
that thinks it's a web browser.

Result: author loses essentially *all* the control that they were
trying so hard to impose.

Result: Verdana reduced in size by a factor 2xY = microfont.

(On the basis of what you were hypothesising, that would be Y*Y,
actually.)

Many find TNR and most other serif fonts not pleasant to read on
screen @ the typical body text size.

Things are slowly improving. Some years back we could confidently say
that although, on a nicely printed page, serif fonts were acknowledged
to be better, nevertheless on a computer screen the greater
readability of sans fonts at low resolution meant that they were the
natural choice for screen display.

But considerable improvements have been made both in display
resolution and in rendering technology, so it's undergoing a
changeover, the way that it seems to me.

[...]

This I consider bad advice, a IE user cannot
specify a minimum font size.

Tools> Internet Options> General> Accessibility

[/] "Ignore font sizes specified on web pages"

(Various other options available there.)

Now I can confidently sit back and wait for the usual chorus of
"IE users never change anything".

The puzzle is this. Those folks keep claiming that IE users browse in
fullscreen mode, but I've never seen an IE installation that wasn't
windowed at installation time. If IE users really *do* never change
anything, as they keep claiming, then clearly that can never happen.

 

[Spartanicus]

Sorry, that doesn't rhyme. The user's choice is the user's choice.
It isn't "reduced" by anything. Sure: it's likely to be a smaller
choice than they would have made if they'd used some other font. But
it's still their choice.

You're right. Another attempt: Authors often specify a size reduction of
Verdana based on the usual pre configured browser serif font, often TNR
@ 16px. Configuring Verdana as the user preferred font @ a smaller size
like 13px therefore results in microfonts for the user on such sites if
no additional measures are taken.

That conflicts with your unreserved endorsement of Verdana as a user
font. Verdana causes as much or more difficulties when used as a user
font.

User's defence: the minimum font size setting (in a good browser)

That possible option does not nullify the drawbacks that result from
using Verdana, if it did then you'd might as well say that there are no
issues with author suggested reduced Verdana body fonts.

Using Verdana as the user font with a minimum font size setting on the
www often causes it's own set of problems like text breaking out of it's
container, or overlapping text, even on relatively well coded sites,
example: http://homepage.ntlworld.com/spartanicus/verdana_trouble.png

, or
the "ignore author font settings" in the operating system component
that thinks it's a web browser.

That causes even more problems on www sites than using Verdana as a user
font with a minimum font size.

Leaving the browser's font setting at the pre configured serif font
prevents these problems. This is why it's imo bad form to simply advise
users to configure their browser font and size to something they like.

Things are slowly improving. Some years back we could confidently say
that although, on a nicely printed page, serif fonts were acknowledged
to be better, nevertheless on a computer screen the greater
readability of sans fonts at low resolution meant that they were the
natural choice for screen display.

But considerable improvements have been made both in display
resolution and in rendering technology, so it's undergoing a
changeover, the way that it seems to me.

Increasing screen resolution causes yet more issues. Current mainstream
OSs use bitmapped UI widgets, these shrink on a higher resolution
screen. As a result the number of screens on the market with a
resolution higher than ~100PPI is very limited. I've used a 148PPI
laptop, using it was a royal pain due to this problem.

If by "improvement rendering technology" you are referring to anti
aliasing of fonts, this can only be achieved by enlarging the text. It
may look nice, but at the expense of efficient use of screen real
estate. I continue to prefer the smaller non anti aliased normal text
and UI fonts used by Windows systems to the bigger anti aliased fonts
that can be generated by for example Linux.

 

[Alan J. Flavell]

[..]
Authors often specify a size reduction of
Verdana based on the usual pre configured browser serif font, often TNR
@ 16px. Configuring Verdana as the user preferred font @ a smaller size
like 13px therefore results in microfonts for the user on such sites if
no additional measures are taken.

That conflicts with your unreserved endorsement of Verdana as a user
font.

"Unreserved"? Let's not go overboard ;-) I haven't chosen it
myself...

But I'm sure it's a perfectly fine choice for an individual to make in
the privacy of their own browser, and *at a size of their choosing*

Verdana causes as much or more difficulties when used as a user
font.

There can be knock-on effects if the author's sizing leaks through,
it's true.

[...]

That causes even more problems on www sites than using Verdana as a
user font with a minimum font size.

Often because the author was trying to impose a fixed layout instead
of adapting to flexible design. Well, that may mean having to disable
yet more of the author's style for successful results. Some
over-designed sites are actually easier to use on Lynx than on the
author's intended browser.

Increasing screen resolution causes yet more issues.

Indeed it does, but solutions are inevitable, since the problem is
increasingly widespread. MS already offers a half-cocked solution
with lots of ifs and buts - presumably they'll be improving it over
time.

Current mainstream OSs use bitmapped UI widgets, these shrink on a
higher resolution screen. As a result the number of screens on the
market with a resolution higher than ~100PPI is very limited. I've
used a 148PPI laptop, using it was a royal pain due to this problem.

As one data point, my office PC works at about 135dpi.

But font size (on a www-compatible browser) isn't the same as
bitmapped images and widgets. Of course I'm assuming that a competent
web designer would be sizing text in em or % units, not in px or pt
units or equivalent.

If by "improvement rendering technology" you are referring to anti
aliasing of fonts,

primarily - and hinting (I'm no expert in font technologies)

this can only be achieved by enlarging the text.

At higher dpi values, a given displayed size of text will have a
higher resolution, that's the point.

cheers

 

[Spartanicus]

"Unreserved"? Let's not go overboard ;-) I haven't chosen it
myself...

"perfectly fine choice" with no mention of the problems that are likely
to result from that choice sounds like an unreserved endorsement to me.

But I'm sure it's a perfectly fine choice for an individual to make in
the privacy of their own browser, and *at a size of their choosing*

Not if that choice of size is anything less than what the user would
chose for a serif font. Verdana is a "perfectly fine choice" as an
author font also, provided that it isn't sized at anything less than
100%, but we all know that people rarely do that. A similar thing
happens when users configure Verdana as a user font.

Indeed it does, but solutions are inevitable, since the problem is
increasingly widespread.

The topic was most people finding serif fonts not pleasant to look at on
the average screen, that issue isn't on the increase.

MS already offers a half-cocked solution
with lots of ifs and buts - presumably they'll be improving it over
time.

What are you trying to achieve with this obscurity?

As one data point, my office PC works at about 135dpi.

That's most unusual if it's not a laptop.

People using CRT monitors often calculate the PPI value based on a the
physical screen dimensions and the desktop screen area setting in the
OS. It's easy to make a mistake with that calculation since the
resolution of a CRT has an upper limit imposed by the granularity of the
phosphor clusters.

But font size (on a www-compatible browser) isn't the same as
bitmapped images and widgets.

No-one is claiming that it is, you suggested that screen resolution was
increasing and that therefore the problem of displaying serif fonts @
body size was getting better. I see no substantial increase in screen
resolution (in PPI) in new screens. I pointed out that current OSs using
fixed size bitmapped widgets is one of the reasons why.

 

[Alan J. Flavell]

The topic was most people finding serif fonts not pleasant to look at on
the average screen, that issue isn't on the increase.

I'd argue that "the average screen" is not a constant. It's evolving.
What my little great-niece uses today is far better than what I used
myself professionally some years ago.

What are you trying to achieve with this obscurity?

Are you asking for a link?

http://msdn.microsoft.com/workshop/author/dhtml/overview/highdpi.asp

"Adjusting Scale for Higher DPI Screens"

That's most unusual if it's not a laptop.

A professional 17inch CRT display, set to 1600x1200

This is quite a normal setting around here (not imposed by me - chosen
by our users).

People using CRT monitors often calculate the PPI value based on a
the physical screen dimensions and the desktop screen area setting
in the OS.

I'm talking about increments of the display system as measured against
an actual physical ruler (and confirmed by the calibration in the OS).

It's easy to make a mistake with that calculation since the
resolution of a CRT has an upper limit imposed by the granularity of the
phosphor clusters.

If there's any "mistake" here it's a misunderstanding about the terms
in use. Read on...

No-one is claiming that it is, you suggested that screen resolution
was increasing and that therefore the problem of displaying serif
fonts @ body size was getting better.

There was a time when most people seemed to have their displays set at
around 72dpi. This is rarely the case now, I think it's fair to say.

Standard TFTs seem to be made for about 95dpi, but as you've said
yourself, there are some which are signficantly higher (albeit you say
you only met them on laptops).

There are indeed two effects, one is the user-chosen display setting
(which is primarily what I was talking about at the time) and the
other, as you rightly point out, is the inherent resolution of the
display itself. Both of them contribute to the final effect. Sure,
there are differences between CRTs and TFTs. With TFTs I'd normally
set to the inherent resolution of the display. With CRTs there's no
harm (and we perceive some benefit) in setting the display system to
somewhat higher values than the inherent physical resolution.

I see no substantial increase in screen resolution (in PPI) in new
screens.

Not that I would take MS's word as gospel, but they evidently thought
it was important enough to implement some kind of a solution, as
already mentioned.

Fortunately, with flexible design techniques, much of this variability
can take care of itself. The only losers are those who continue to
insist that they have to control the final result so hard that it
hurts.

 

[Spartanicus]

I'd argue that "the average screen" is not a constant. It's evolving.
What my little great-niece uses today is far better than what I used
myself professionally some years ago.


Are you asking for a link?

Did you expect anyone to know what you were talking about based on what
you wrote?

http://msdn.microsoft.com/workshop/author/dhtml/overview/highdpi.asp

"Adjusting Scale for Higher DPI Screens"

The above referenced MS method only to some extent affects the content
displayed in a web browser viewport. The issues resulting from higher
resolution screens affect everything displayed on screen, which is why I
brought up OS UI widgets. It is an issue that needs to be tackled by the
OS, not by individual applications, and certainly not just for their
document rendering space. Tackling the issue definitively would require
a fundamental change in the way that UI widgets are defined and
rendered.

A professional 17inch CRT display, set to 1600x1200

This is quite a normal setting around here (not imposed by me - chosen
by our users).


I'm talking about increments of the display system as measured against
an actual physical ruler (and confirmed by the calibration in the OS).

A "calibration in the OS" cannot reliably establish the actual
resolution of a CRT viewing device since it does not take into account
the granularity of the phosphor clusters.

Most, if not all CRT monitors can handle screen area settings that
exceed the capability of the CRT by a considerable margin.

If there's any "mistake" here it's a misunderstanding about the terms
in use. Read on...


There was a time when most people seemed to have their displays set at
around 72dpi. This is rarely the case now, I think it's fair to say.

Standard TFTs seem to be made for about 95dpi, but as you've said
yourself, there are some which are signficantly higher (albeit you say
you only met them on laptops).

There are indeed two effects, one is the user-chosen display setting
(which is primarily what I was talking about at the time) and the
other, as you rightly point out, is the inherent resolution of the
display itself. Both of them contribute to the final effect. Sure,
there are differences between CRTs and TFTs. With TFTs I'd normally
set to the inherent resolution of the display. With CRTs there's no
harm (and we perceive some benefit) in setting the display system to
somewhat higher values than the inherent physical resolution.

There is no inherent physical resolution for CRT monitors, they have a
*maximum* resolution imposed by the CRT. If the screen area setting is
lower than that maximum value, then that is the resolution you get.

There most definitely is harm in setting the screen area setting at a
value beyond what the CRT can display, information is lost when you do
that. This may not be apparent by judging the result on esthetics, in
fact it may even appear to be more pleasing to the eye, but you are
deluding yourself.

Not that I would take MS's word as gospel, but they evidently thought
it was important enough to implement some kind of a solution, as
already mentioned.

Fortunately, with flexible design techniques, much of this variability
can take care of itself.

The issue of considerable variations in screen resolution has a profound
effect not only on the requirements for OS UI widgets, but on all
current bitmapped resources including bitmapped web content. This
potential issue will not "take care of itself".

If by "flexible design techniques" you are referring to variations in
user viewport size and that content should adapt to it, then this is an
entirely different topic.