At the November F2F one of the issues that came up was what exactly should happen when font-specific features are set and fallback occurs. Using the notation in the current draft, consider this situation:
body {
font-family: MyFancyFont, SomePlatformFont;
font-variant: additional-ligatures styleset(1,3);
}
This enables the use of discretionary ligatures and enables stylistic variant glyphs. Here the intent is to enable them for MyFancyFont. The 'styleset(1,3)' value enables OpenType features ss01 and ss03, features that are defined per-font. There's no consistent meaning to these values across fonts. If fallback occurs, stylistic variants in SomePlatformFont will be also be used which isn't desired.
Note that this would only matter in cases where stylistic variants existed in the fallback font for characters not in the first font in the list. That's generally unusual today but not guaranteed to be that way in the future. To me the most likely scenario is when MyFancyFont supports a limited number of scripts and SomePlatformFont is a steroid-consuming super font with support for all sorts of languages and scripts and variations for each.
There are a few options here:
1. This is a rare problem, authors should choose their fonts carefully.
2. 'font-variant' properties only apply to the first font
3. The syntax of the 'font-variant' property includes a font family name to control specificity. Something like:
font-variant: MyFancyFont / additional-ligatures styleset(1,3), SomePlatformFont / additional-ligatures;
With this syntax, stylistic variant sets are only used when MyFancyFont is used, not when fallback to SomePlatformFont occurs.
4. Add descriptors to the @font-face syntax to specify font-variant settings that only apply to a single face:
@font-face {
font-family: MyFancyFont;
src: url(font.ttf);
font-variant: styleset(1,3);
}
body {
font-family: MyFancyFont, SomePlatformFont;
font-variant: additional-ligatures;
}
Same as (3), stylistic variant sets are only used when MyFancyFont is used, not when fallback to SomePlatformFont occurs. The 'font-variant' descriptor isn't used in font selection, it's used as a rendering property.
As written currently the spec supports (4) rather than (3). This allows per-font defaults that can be overridden with general controls, it seems more flexible to me. Proposal (3) seems like it doesn't work very cleanly with inheritance, and you've set up a fuzzy linkage between font-variant and font-family that seems brittle. Also, there are some properties that are font-specific but some like the number formatting features that are not, with (3) you'd need to divide up features in some way and I think that's a confusing distinction for authors to work with. Method (4) is clumsy for use with platform fonts but not impossible if really necessary, src local() can be used to define font families with specific default properties.
Thoughts/comments?
John Daggett