W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: [css3-fonts] new editor's draft

From: John Daggett <jdaggett@mozilla.com>
Date: Wed, 21 Jan 2009 08:27:29 -0800 (PST)
To: Michael Day <mikeday@yeslogic.com>, www-style <www-style@w3.org>
Message-ID: <1302434.6258281232555249496.JavaMail.root@cm-mail01.mozilla.org>

Hi Michael,

Going back to your original posting on this back in November:

> It allows you to define font families with intelligent fallback:
> @font-face {
>   font-family: MyFont;
>   src: local("Times New Roman"), local("OpenSymbol"), ...
> }
> In the Prince default style sheets we actually use this to predefine the 
> default font families such as "serif" and "sans-serif".

This seems simple, but to really make this work you're going to need
four rules to cover each of the four common style variations - normal,
bold, italic and bold italic, since a single @font-face rule only
defines a single *face* within a family.

It really seems like you're interested in a way of aliasing a set of
*families* so that wherever 'MyFont' is used, Times New Roman followed
by OpenSymbol, etc. are substituted.  Maybe:

@font-alias {
  font-family: MyFont;
  alias: Times New Roman, OpenSymbol, ...;

Or maybe just something from CSS Variables?

If the src is defined in such a way that user agents need to iterate
over all the fonts in the list for font fallback, you lose the ability
to control prioritized load behavior.  In the example below, the author
would like to use a locally available version of Futura but substitute a
SVG font if it's not available, or an TrueType font otherwise.  Assume
for simplicity that each of these fonts has the same character map.

@font-face {
  font-family: MyFutura;
  src: local(Futura Medium), url(MyGeometricModern.svg) format("svg"), url(FakeFutura.ttf) format("truetype");

If you defined the src descriptor the way you propose, user agents that
implement SVG fonts would *always* need to download the TrueType font,
even if you separated these out into three separate @font-face rules and
used MyFutura1, MyFutura2, MyFutura3 in all your font-family lists.

For another example, complex scripts such as Arabic require special data
within the font, and the necessary data varies across platforms, on
Windows you need a font with OpenType Layout tables, on Mac OS you need
a font with AAT tables.  To support both platforms, the Arabic font
Scheherazade (Jonathan Kew, please take a bow) comes in two forms, one
for OpenType and one for AAT.

@font-face {
  font-family: Scheherazade;
  src: url(ScheherazadeRegAAT.ttf) format("truetype-aat"),  url(ScheherazadeRegOT.ttf) format("opentype");

With src defined to iterate over the list during font fallback, the
OpenType version of Scheherazade would always be downloaded, even though
it wouldn't be needed on the Mac.

> While it is possible to concoct scenarios involving combinations of
> local fonts, downloaded fonts, different unicode-ranges and subtle
> fallback behaviour to result in a perfect appearance, I wonder how
> common these will actually be.

For a wide variety of sites, there's probably not a whole lot of need
for complicated scenarios involving unicode-range.  Those sites can
still use @font-face in a very simple way, no need to worry about
unicode-range.  But for sites that are multi-lingual, knowing which
fonts to use for which locales and dealing with this complexity is an
ongoing problem.  Being able to use unicode-range in the way that it's
currently implemented in WebKit is a huge win for these sites.


John Daggett
Mozilla Japan
Received on Wednesday, 21 January 2009 16:28:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC