Should font-variation-settings be a property, a descriptor, or both?

[dbaron]

Fonts Level 4 introduces a font-variation-settings property that sets particular variation parameters. These seem likely to be reasonably specific to particular fonts, although I'm not entirely sure how much.

That they're specific to fonts makes me suspect that it may make more sense for this to be available as a descriptor so that a font-variation-settings doesn't accidentally apply to a fallback font. This seems like it could become more problematic as system fonts (which are likely to be fallback) become more likely to support OpenType variations.

I wonder whether font-variation-settings should be available as a descriptor in addition to a property (like font-feature-settings), or maybe even instead of a property.

I got here from w3ctag/design-reviews#183.

[dbaron]

@plinss points out that animation is only possible with a property

[litherum]

You are right that only certain fonts will respond to certain axes, but the meaning of a particular value on a particular axis is expected to be consistent between fonts. This is why the high-level properties of font-weight, font-style, font-stretch, and optical-sizing are preferable over font-variation-settings because their behavior is well-defined over all fonts. This works the same way as font-feature-settings.

[css-meeting-bot]

The CSS Working Group just discussed TAG Review of variable fonts, and agreed to the following resolutions:

• RESOLVED: font variations will be both properties and descriptors

The full IRC log of that discussion

<fremy> Topic: TAG Review of variable fonts
<TabAtkins> GitHub: https://github.com/w3ctag/design-reviews/issues/183
<fremy> github: https://github.com/w3ctag/design-reviews/issues/183
<fremy> dbaron: ??? asked for tag review
<eae> s/???/drott/
<fremy> dbaron: the main feedback was how this should be font properties or descriptors
<fremy> dbaron: the reasoning should be that some things should be whether you would want the things to apply to fallback fonts or not
<fremy> dbaron: over time, system fonts are likely to get more variations
<TabAtkins> Looks like the axixes would be best done as an open-ended set of properties, similar to custom properties...
<fremy> myles_: there are two spaces
<TabAtkins> We can't guarantee that the axis names live in the CSS ident space, so we can't do `font-axis-*` tho.
<fremy> myles_: one is for things that are defined for all fonts
<fremy> myles_: and things that are custom for your own font, which are used in all caps
<fremy> TabAtkins: what is the ascii range for these names?
<fremy> myles_: less than ascii for sure
<fremy> myles_: no control char or anything, and casing does matter
<fremy> dbaron: flip side is animation
<fremy> dbaron: if you want to animate them, they should be properties
<fremy> eae: there have been clear request to support that
<fremy> dbaron: I think it would make sense then to have both to support both use cases
<fremy> myles_: this is what font-feature-settings is, minus some stories I rather not start talking about
<dbaron> github: https://github.com//issues/1652
<fremy> TabAtkins: how about having a list of values in the axis?
<fremy> TabAtkins: we still need to be able to control them independantly
<fremy> TabAtkins: we can instead allocate a property namespace so that you get a property for each axis
<fremy> fantasai: the issue is that each axis might change of ascii range in newer formats
<fremy> TabAtkins: you can escape any char in identifiers in css
<fremy> myles_: in our impl we would not want that anyway
<fantasai> s/the issue is that each axis might change of/what if axis idents are outside/
<fremy> s/that/weird axis names/
<fremy> alan: use case where you have weight animated
<fremy> myles_: you can animate pair by pair
<fremy> TabAtkins: but you still need to change all of them in same declaration
<fremy> myles_: additive css would solve that
<fremy> TabAtkins: yes
<fremy> myles_: so, based on consensus we need a resolution to add descriptor and keep property
<fremy> fantasai: we have a similar problem with various stylistic fonts tags you want to turn on and off
<fremy> fantasai: what we did, we decided to tie them to an identifer that is font-specific
<fremy> fantasai: we could take the same approach here
<fremy> fantasai: this would allow to customize a font-specific thing in particular without affecting other fonts
<fremy> myles_: that would work for named axises but some are just number-indexed
<fremy> TabAtkins: also the ranges could not mean the same thing for each font even if name is identical
<TabAtkins> s/name is identical/the two axises do approximately the same thing/
<myles_> That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts
<fremy> alan: even the lower-case standardized names, do they have identical ranges?
<fremy> myles_: no
<fremy> myles_: names are consistent between formats, but ranges are not
<fremy> myles_: they are internally consistent per format though
<fremy> alan: could we map one to the other?
<fremy> myles_: yes, we could map to a canonical form
<TabAtkins> s/myles_: that would work for named axises but some are just number-indexed/That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts/
<fremy> alan: so could we define a css range?
<fremy> myles_: I don't want to get into that
<fremy> alan: anyway, I didn't hear any opposition to have things be both font descriptors and properties as per tag review
<fremy> alan: can we get this resolved?
<Bert> q+ to ask (about previous topic) what 'font-synth: no-weight style' means for small-caps: Is small-caps synthesis on (beacuse it is not explicitly turned off) or off (because it is not explicitly turned on)?
<fremy> RESOLVED: font variations will be both properties and descriptors
<fremy> alan: any other issue we should discuss from this review?
<fremy> dbaron: not really, the rest is mostly editorial
<astearns> ack Bert
<Zakim> Bert, you wanted to ask (about previous topic) what 'font-synth: no-weight style' means for small-caps: Is small-caps synthesis on (beacuse it is not explicitly turned off) or off
<Zakim> ... (because it is not explicitly turned on)?
<fremy> Bert: so font-synthesis: no-abc --> turns off abc but on def, right?
<fremy> myles_: well, it resets def to its default
<fremy> myles_: right now all the other values are on by default, but in the future we could add new things that would be off by default
<fremy> Bert: then why should we not change the fonts spec
<fremy> myles_: no, it would just do as today, the spec will still be internally consistent
<fremy> fantasai: well, new features will be off by default all the time right? otherwise it will be breaking change
<fremy> Florian: not really, because new features could be things that did not exist at all before
<fremy> Florian: so there would be no possible backwards compat problem
<fremy> fantasai: and small-caps?
<fremy> myles_: it is not in level 3, so no revision to do
<fremy> fantasai: but with this we could backport to level 3
<fremy> fantasai: wouldn't you want that then?
<fremy> myles_: to prevent a browser that support "small-caps" but "not-smallcaps"?
<fremy> fantasai: yes
<fantasai> fantasai: We could have small-caps be on in the initial value and also be on if omitted
<fremy> dbaron: well, i think there is still a change from level 3
<fantasai> fantasai: The ability to do this is effectively why we are considering having this foo/no-foo syntax.
<fremy> TabAtkins: this is not the same default we are talking about
<fremy> TabAtkins: now we talk about "default if you omit it in the declaration" not the "default if you omit the declaration"
<fremy> dbaron: is this widely implemented?
<fremy> myles_: no
<fremy> dbaron and tabatkins arguing about default vs initial
<fremy> dbaron: i would want the default to be the same as the initial
<fremy> fantasai: +1
<fantasai> s/default/default if omitted/
<TabAtkins> [dbaron kept using "default" to mean "initial value", when I and Myles were purposely using "default" to mean a totally separate concept]
<fremy> fantasai: if we don't do what david wants, yes, there is not breaking change

[litherum]

It's already a property, so it needs to be a descriptor too.