W3C home > Mailing lists > Public > www-style@w3.org > November 2015

Re: [css-fonts-4] compat problem with 'system' generic font family?

From: John Daggett <jdaggett@mozilla.com>
Date: Tue, 10 Nov 2015 10:55:28 +0900
Message-ID: <CALYZoVPuQsHrX09=fATKZ_EhaHSSNovXOk-FCGmZtJUkGuj-wg@mail.gmail.com>
To: Alan Stearns <stearns@adobe.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org" <www-style@w3.org>, "Myles C. Maxfield" <mmaxfield@apple.com>
Alan Stearns wrote:

> Authors will (and should) support older browsers for quite a long
> time. Even after all of the current browsers support the ‘system’
> value it won’t be safe to use on Windows for years. So they’ll add
> ‘-apple-system’ without the unprefixed generic to their font stacks
> (as Medium has done now) which may force everyone to implement the
> prefixed version (I believe Firefox is already considering this).

The ancient Windows 3.0-era font 'System' exists on XP but not on
Windows 7 or anything more recent. So I don't really see a great need to
use something more awkward simply to avoid name conflicts with 'system'.
By the time it's implemented in user agents the need to support XP-level
systems will be a thing of the past. Authors can use available
techniques for supporting antique browsers.

There's actually a little bit of a complicated backstory to the use of
'-apple-system' under OSX and iOS. There are several distinct features
that make this a "special" font family:

  o Hidden font family name. Apple considers this a "hidden" family, not
    one that is generally accessible via the family name. The platform
    provides API's to access the "system font" but their use is not
    really well-documented and their use feels like a work in progress.

  o Size-specific font selection. There's one set of faces for text
    sizes and a larger set of faces for display sizes (the cutoff is at

  o Tracking. In addition to choosing a given face (text or display)
    based on the size, there's additional tracking that's applied based
    on the size to aid readability at smaller sizes (via data in the
    'trak' table).

  o Linked fallback fonts. There are other hidden families for other
    scripts to which San Francisco is automagically "linked". So using
    text shaping under OSX 10.11, the system font will automatically
    fallback to the right set of hidden system fonts for Japanese. Note
    that this means that Latin text within Japanese menu items appear in
    San Francisco, not using the Latin glyphs in hidden Japanese system

Under the latest versions of OSX and iOS, having some form of meta-name
for the system font is actually not just a "nice to have", it's a
*requirement*! Eventually a general keyword 'system' can map to the same
thing across platforms but for now using '-apple-system' to deal with
these special, hidden system font families under OSX and iOS is fine.

I added support for '-apple-system' to Firefox rather than create a new,
Firefox-specific name. The Blink folks apparently added "BlinkMacSystemFont"
but frankly that name should be taken out to the woodshed and put out of
its misery. :P Replacing these with a 'system' keyword eventually is a
good thing.

A side note is that it sucks to some degree that authors need to futz
with special lists of system fonts. The CSS2 system font keywords were
designed to fill this need. Unfortunately, on mobile *no* implementation
does them this correctly. Safari/iOS, Chrome/Android and Firefox/Android
all map to random default or weird meta fonts rather than the system UI
font. [2] *sigh*


John Daggett
Mozilla Japan

[1] Fabulous intro to new OSX system fonts! Yes, type design is cool...

[2] I didn't test Windows Phone. Here's a testpage to check:
Received on Tuesday, 10 November 2015 01:55:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC