Re: [css3-fonts] font-specific feature handling

On 03/18/2010 07:31 AM, John Daggett wrote:
> In the telecon this week one of the topics discussed [1] was
> font-specific font variant features in the CSS3 Fonts spec [2].  The
> original post on this is here:
> ...
> Allowing both gives authors flexibility but I really don't like the
> idea of restricting font-specific values to @font-face rules, it makes
> normal authoring more cumbersome because an @font-face rule would need
> to be defined for *each* combination of restricted values:
>
>    @font-face {
>      font-family: MyFancyFont-Ornament1;
>      font-variant: ornaments(1);
>    }
>
>    @font-face {
>      font-family: MyFancyFont-Ornament3;
>      font-variant: ornaments(3);
>    }
>
>    @font-face {
>      font-family: MyFancyFont-Headings;
>      font-variant: swash(1) styleset(6);
>    }
>
>    @font-face {
>      font-family: MyFancyFont-Text;
>      font-variant: styleset(2,3);
>    }
>
>    p.special:first-letter { font-family: MyFancyFont-Ornament1; }
>    p.regular:first-letter { font-family: MyFancyFont-Ornament3; }
>    h1, h2 { font-family: MyFancyFont-Headings; }
>    p.special { font-family: MyFancyFont-Text; }
>
> Dang, that's verbose!  Compare this to using just the general property:
>
>    p.special:first-letter { font-variant: ornaments(1); }
>    p.regular:first-letter { font-variant: ornaments(3); }
>    h1, h2 { font-variant: swash(1) styleset(6); }
>    p.special { font-variant: styleset(2,3); }
>
> In general, it's really, really hard to construct an example where
> fallback occurs and anything other than the default glyphs are used.
> Most platform fonts lack alternate variants.

And will that be true 5 years from now? Microsoft has taken to shipping
some pretty high-quality fonts with its Windows and Office products.
And IIRC Apple ships with fonts that show off its APIs, too. Chances
are that trend will continue. Even Ubuntu is looking into acquiring
better fonts.

Note also that fallback is triggered not just in cases where you are
missing the intended font, but also in cases where multiple fonts are
needed to render the content. E.g. I could pick a nice Latin font,
and pair it with a nice Chinese font. As I try to tweak the Latin, I
might inadvertently trigger changes in the Chinese.

> Where authors run into the exceptional situation in which fallback
> rendering is somehow a problem, the ability to specify font-variant
> values in @font-face rules would provide a way to work around these
> problems.

As Peter mentioned, authors are unlikely to notice the problem because
their computers are usually not the ones triggering fallback.

> I think we're all accustomed to dealing with font stacks and fallback
> issues but with downloadable fonts, that's really an old paradigm.  In
> a world where web fonts are ubiquitous, an author specifies the font
> they want and doesn't worry so much about fallback.  I don't think we
> should make authoring more difficult in this situation for the sake of
> fallback problems that are theoretically possible but generally don't
> occur in practice.

You may consider the problem unimportant, but there are several WG
members that disagree. If @font-face rules are unnecessarily unweildy,
design a better alternative. The feedback you've gotten is that
font-specific settings should be tied to the font, because whether or
not they're likely to fail gracefully, they have no consistent or
predictable meaning across font faces: once fallback is triggered,
you get a random result. A style set that triggers swishy ascenders
and descenders for my heading in one font might trigger a esszet -> SS
transformation in another.

~fantasai

Received on Thursday, 18 March 2010 21:02:00 UTC