Re: [csswg-drafts] [css-fonts-4] [varfont] local() and variation fonts

I'd like to list a few scenarios:

1. An OS is released which understands variations and expands a 
preexisting font to support variations. Web authors start specifying 
variation values in their CSS. New systems work correctly with 
variations. Old systems don't understand variations at all, so there 
is no font (not even a web font) that can show the desired variation 
values. In this situation, the web author needs to define fallback for
 older systems (which is discussed elsewhere).

2. An OS is released which understands variations. Then, in a 
subsequent OS release, a preexisting variation font is expanded to 
support more variation axes. In this situation, an identifier of "does
 this font support variations or not" does not help. Here, you really 
need to discover which axes a particular font supports, which is 
discussed in https://github.com/w3c/csswg-drafts/issues/520

3. An OS is released which understands variations. Then, in a 
subsequent OS release, a preexisting non-variation font is expanded to
 support variations. I'd like to hear from OS vendors to know if this 
is likely to occur. Any solution to case 2 would also solve this case,
 so it seems like we should pursue that instead.

4. An OS is released which understands variations. Then, in a 
subsequent OS release, a new font is included which is a variation 
font. The regular font-family fallback list handles this case.

5. A user installs an unknown font over top a preinstalled font. There
 is nothing anyone can do here, because the user-installed font could 
be anything. The web author has no data upon which to make a decision.
 (And, as I mentioned before, some UAs may wish to ignore the 
user-installed font).

-- 
GitHub Notification of comment by litherum
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/512#issuecomment-253949944 
using your GitHub account

Received on Saturday, 15 October 2016 00:32:31 UTC