[css-text] [css-fonts] Variation selectors are underspecified

[litherum]

Variation selectors require some extra processing to get them right. There are two reasons for this: The 'cmap' format 14 subtable allows character mapping to accept variation selectors as input, and variation selectors are required for emoji selection but optional for other purposes.

This has implications for the unicode-range descriptor in @font-face, the font matching algorithm, and a possible property being discussed at #352.

It seems to me that it's valuable for browsers to have interoperability regarding variation selectors.

Before making a specific proposal, I'd love to hear from the browser vendors about their current (or planned) support of variation selectors.

cc @heycam @drott @PeterCon

[litherum]

Currently, WebKit has no concept of variation selectors. However, macOS and iOS do. In CoreText, VS15 and VS16 are treated specially.

If a code point has VS16 attached to it, font selection will only ever select a color font to show the code point (if one exists). If a code point has VS15 attached to it, font selection will never select a color font. A color font is one which has an appropriate table (e.g. sbix) (which can be queried by checking if the CTFontSymbolicTraits has the kCTFontTraitColorGlyphs bit set). No other variation selectors affect font selection. Once a font is chosen, an unsupported variation selector is just ignored.

[kojiishi]

I support the idea to define it better. Blink has similar logic in SymbolsIterator, but there are some edge cases I would like to test more.

In regards to VS in the font selection, I believe the spec defines the cascading for VS in general; e.g., when font-family: A, B, and when A has the base character but doesn't have the specified VS, UA must chose B if B has the VS, or A otherwise.

[upsuper]

cc @jfkthame

[css-meeting-bot]

The Working Group just discussed Variation selectors are underspecified.

The full IRC log of that discussion

<fantasai> Topic: Variation selectors are underspecified
<fantasai> github: https://github.com//issues/854
<frremy> (koji to read the issue, as he doesn't remember commenting on it)
<frremy> myles: there isn't a proposal, it's more of a discussion topic
<frremy> fantasai: the question is that there is a text
<frremy> fantasai: and the main font supports the base char, not the variation selector
<frremy> fantasai: the fallback font supports both
<frremy> fantasai: do you fallback or not?
<frremy> myles: there are two special ones that doesn't need font fallback
<frremy> myles: but unicode doesn't support font-fallback
<frremy> koji: it seems reasonable to make 15 and 16 specials
<frremy> myles: they should affect fallback
<frremy> myles: they should match together
<frremy> fantasai: so you must match a font that supports both
<frremy> myles: correct
<frremy> myles: the way we implemented this is that when you have a color indicator
<frremy> myles: we will only search color fonts
<frremy> myles: if there is a font that supports the glyph but not the color variations, we will skip it
<frremy> myles: it's not that I'm proposing this, because each OS might do this differently, but this is a reference to keep in mind
<frremy> fantasai: for cjk, there is the option of doing a two-pass behavior or a single-pass variant
<frremy> fantasai: but there seems to be use cases for both
<frremy> florian: for instance an ID name want to right char
<frremy> fantasai: but as a designer, you want to stay with the same font, and dropping the variation is better
<frremy> florian: I recall discussing this at the first meeting I ever attended
<frremy> florian: that was long ago
<frremy> myles: I don't think we are going to make any progress on this issue
<frremy> myles: we should probably switch

[frivoal]

We have a resolution from the 2011 F2F in Kyoto about font fallback for variations selectors:

RESOLUTION: font fallback goes all the way to system fallback with the IVS before repeating with base, will add a property to switch between that and font-consistency-priority matching

https://lists.w3.org/Archives/Public/www-style/2011Jun/0325.html