[css-fonts-4] Wide gamut `@font-palette-values` entries and platform limitations

[drott]

https://drafts.csswg.org/css-fonts/#font-family-2-desc

says:

Value:	<'font-family'>

linking to

https://drafts.csswg.org/css-fonts/#propdef-font-family

which is:

Value:	[ <family-name> | <generic-family> ]#

which makes it look like

1. the font-family descriptor in @font-palette-values should be able to assume a comma-separated list of family names as a value, which I don't think is the case.

2. generic family names are allowed here, which is also not the case according to the prose in 9.2.1.

I suggest to use a different, new value type definition to fix this.

CC @svgeesus @litherum

[drott]

Or perhaps by splitting out the separate value definitions / parsing rules for family-name and generic-family and using only family name here.

[jfkthame]

See also #7308, where I also stumbled across this section. As noted at #7308 (comment) there, there's an example that implies a comma-separated list is allowed.

[jfkthame]

While my previous comment is not actually relevant, as I had misread the example, I do think that the font-family descriptor in @font-palette-values should be allowed to take a list of family names.

In most cases, font palette overrides will be targeted at one specific font, but I don't think it's much of a stretch to imagine a suite of decorative fonts designed to work together and with coordinated palettes, in which case it could well make sense to apply the same color overrides to several families.

The somewhat analogous @font-feature-values at-rule is quite explicit that it does accept a list of family names (and the syntax and the prose agree on this!).

I notice that the current @font-palette-values implementations in Webkit and Blink do not accept a list, only a singular family name. @drott @litherum Would you be open to updating this to accept a list, if the WG agrees to resolve the current ambiguity in that direction?

[svgeesus]

The first part of the prose for that descriptor reads like a single family is used, while the second part of the same text explicitly says a list (my emphasis)

This descriptor defines the font family name that this palette applies to. This palette will only ever be applied to the font with this name. The value of this descriptor matches the definition of the for the font-family property.

This means that only named font families are allowed and rules that including generic or installed fonts in the list of font families are syntax errors. If syntax errors occur within the font family list, the entire rule must be ignored.

[jfkthame]

Exactly; the spec text is quite confused. As mentioned in #7308, there's also the question of whether the names of installed font families are allowed. (I think they should be; the spec currently contradicts itself.)

[svgeesus]

The spec seems clear that names of installed font families are not allowed:

rules that including generic or installed fonts in the list of font families are syntax errors

What text were you reading that indicated they were allowed?

[jfkthame]

Isn't that implied by "The value of this descriptor matches the definition of the for the font-family property"?

[jfkthame]

I agree with excluding generic families, incidentally -- which means that "matches the definition of the for the font-family property" is not an accurate way to describe the value of this descriptor.

Further, I'm surprised the text says "If syntax errors occur within the font family list, the entire rule must be ignored". Wouldn't it be more normal to ignore the descriptor where the error occurs, not the entire rule? That seems to be what both Safari and Chrome are doing.

[svgeesus]

Aha, okay. Yes that needs to be changed to a new production which is syntactically similar but adds the "no generic font families" restriction.

Wouldn't it be more normal to ignore the descriptor where the error occurs,

It would, but (unless there is a later, duplicate, valid) font-family descriptor then the at-rule doesn't apply to anything.

[jfkthame]

It would, but (unless there is a later, duplicate, valid) font-family descriptor then the at-rule doesn't apply to anything.

True; but as currently written, a font-family descriptor with a syntax error (such as a generic name) would cause the entire rule to be dropped, even if there's a subsequent, valid font-family descriptor. (Which is not how any existing implementation behaves, AFAICT.)

What about a rule with no font-family descriptor at all? The text currently says:

@font-palette-values rules require a font-family descriptor; if it is missing, the @font-palette-values rule is invalid and must be ignored entirely.

Does this mean that the rule should be dropped at parse time, and not appear in the OM, or it it simply telling us that the rule will not apply to anything and therefore "must be ignored entirely"?

(Existing implementations appear to accept a rule that lacks font-family, and https://github.com/web-platform-tests/wpt/blob/master/css/css-fonts/parsing/font-palette-values-valid.html thinks they're valid even though they're pointless. Is that the intention, or are the implementations and the testcase incorrect?)

[jfkthame]

Another reason not to treat installed font-family names as a syntax error is that this provides a convenient fingerprinting method to probe for what fonts are installed on the user's system.

And another reason is that although a given family name might not have been defined by @font-face at the time the @font-palette-values rule is parsed, it might be defined by a later at-rule. Such a name should not be a syntax error here.

[svgeesus]

Both good reasons!

[svgeesus]

Does this mean that the rule should be dropped at parse time, and not appear in the OM, or it it simply telling us that the rule will not apply to anything and therefore "must be ignored entirely"?

I think it means that it won't apply to anything. It will still be in the OM. That text should be clarified.