Scripsit Roedy Green:
Quote:
Quote:
>body { font: 1em serif }
>
Thanks for your speedy response. I realise now that I do that
already.
Then you should do something about that problem.
Quote:
Here is a related question, which is the one I should have
asked in the first place.
We might be getting closer to your real question, and it isn't related
to the question you originally asked.
Quote:
What if you have 3 basic font-family patterns on your website?
You just decide which elements you wish them to apply to, then write
appropriate selector lists.
Quote:
e.g.
>
for body text
font-family: "Tiresias PCfont Z","Tiresias
PCfont",TiresiasScreenfont,"Palatino Linotype","Bookman Old
Style","Book Antiqua","Trebuchet MS","Lucida Sans","Lucida Sans
Unicode",Verdana,serif;
>
for title-like elements:
font-family: Calibri,"Bitstream Vera Sans","Segoe
UI",Arial,Helvetica,sans-serif;
>
for monospaced elements:
font-family: "Bitstream Vera Sans Mono","Lucida
Console","Lucida Sans","Lucida Sans Unicode","Courier","Courier
New","Bitstream Vera Sans","Segoe UI",Arial,monospace;
How many of the possible combinations did you actually test visually? It
seems that you have written the lists almost at random. For example,
what will happen when Verdana is used for copy text, Calibri for
headings, and Arial for "monospaced" elements? Quite a mess, I would
say.
For example, what does Verdana do in the list for body text
alternatives? It would seldom be used, since e.g. Palatino Linotype has
probably well over 90% coverage in computers, but if it were used for
some odd reason, the page appearance would be _very_ different from the
effects of most of the other fonts you're suggesting.
The Tiresias fonts are rather rarely installed, but if you have verified
that their overall appearance is similar to Palatino Linotype but even
better for your purposes, then the following would be a reasonable
starting point:
* { font-family: "Tiresias PCfont Z","Tiresias
PCfont",TiresiasScreenfont,"Palatino Linotype", serif; }
Then you just add rules for elements for which some other font is
preferred.
For title-like elements, you have too many alternatives, too. For
example, what are the odds of having Segoe UI in a system that lacks
Calibri? And what is your general strategy? If you prefer Calibri for
title-like elements, it would be natural to use Cambria or Constantia
for copy text, Consolas for monospace text, since the "C fonts" have
been designed to be used together. They are generally smaller than most
other fonts, for a given font size (!), but they match each other's
dimensions, so that e.g. Consolas text inside Cambria text looks
reasonable (whereas, in general, monospace text inside normal text too
often looks disproportional).
For example, assuming that Palatino Linotype is really your basic
preference for copy text, you should probably have something simple for
title-like elements, e.g.
h1, h2, h3, h4, h5, h6, caption, th, .caption {
font-family: Helvetica, Arial, sans-serif; }
(and you would use class="caption" for any element that you want to
appear in your "title style" but lacks natural markup, e.g. image
caption).
Quote:
Is there a way to specfy each pattern only once, then just indicate
which pattern applies to any given style?
No.
Quote:
If not, is there a way to specify the preferred font-family set you
would like to use for logical fonts monospace , sans-serif and serif?
By using a list of selectors that contains the elements you want the
font-family to be used for.
Quote:
If not, is there any way to create user-defined inheritance hierarchy
No. Inheritance works as defined in CSS specifications, and in a manner
that most people don't understand. Forget inheritance for the time
being. If you specify font-family for every element (as you would e.g.
by writing * { font-family: ... }), then no inheritance will take place
for that property.
Quote:
I heard CSS was developing constants/variables, that might be useful
to solve such a problem.
The Internet is full of rumors. This one is particularly wrong, since
the W3C has made a policy decision not to develop CSS in the direction
of a programming language. Of course, they might be somewhat
inconsistent in this matter, as others, but it would be very unrealistic
to expect CSS to develop (named) constants or variables.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/ 
