[css-fonts] issues with font-family descriptor in @font-palette-values rule

[jfkthame]

The @font-palette-values rule has a font-family descriptor[1] that is supposed to associate it with a particular font ("This palette will only ever be applied to the font with this name").

However, this seems problematic to me, as font-family does not identify "a particular font" but a family that may contain an arbitrary number of faces; and (thanks to the magic of unicode-range) any given face might refer to an arbitrary number of font resources. Each of these may have its own palettes.

Therefore, when the base-palette descriptor[2] "specifies a palette in the font...", it is (AFAICS) not fully specified which font resource (and therefore which palette) is meant.

[1] https://www.w3.org/TR/2017/WD-css-fonts-4-20170711/#font-family-2-desc
[2] https://www.w3.org/TR/2017/WD-css-fonts-4-20170711/#base-palette-desc

[litherum]

Because the other font selection properties (font-weight, font-style, font-stretch) won't change during font fallback for a particular element, font-family is sufficient to be applied differently to different fonts during fallback on a particular element. @font-palette-values is applied independently to each element, so it seems well-defined to me.

Am I misunderstanding you?

[jfkthame]

Hmm, OK; I think I hadn't fully grasped the implications of @font-palette-values being "applied independently to each element".

That still leaves the question of a single face (family/weight/style/stretch combination) that is backed by multiple font resources (via @unicode-range), where each resource has its own independent palettes. Does @font-palette-values in fact need to be resolved independently for each character [cluster] of each element, after per-character fallback has been performed?

I'm concerned at how complex and perhaps expensive this is sounding, but admittedly that's without having attempted any kind of implementation.

[svgeesus]

That still leaves the question of a single face (family/weight/style/stretch combination) that is backed by multiple font resources (via @unicode-range), where each resource has its own independent palettes.

Hmm, good point. Compound fonts would be problematic with the current approach.

[litherum]

Does @font-palette-values in fact need to be resolved independently for each character [cluster] of each element, after per-character fallback has been performed?

Right now, yes. This is how @font-feature-values already works. In our implementation (which doesn't exist yet), I don't expect this to be more difficult to implement than @font-feature-values.

[css-meeting-bot]

The Working Group just discussed issues with font-family descriptor in @font-palette-values rule, and agreed to the following:

• RESOLVED: Add normative text describing this issue and being more clear about how this all works with an example for how things can go terribly wrong

The full IRC log of that discussion

<dael> Topic: issues with font-family descriptor in @font-palette-values rule
<dael> github: https://github.com//issues/1669
<dael> chris: I think basic problem is spec says if you say font-family it will be unique IDed. fine for fallback between diff families. Composit font there is no guar there is the same pallate with same palette values.
<dael> myles: Proposal to solve? I think as-is is fine and authors should make composite fonts correctly.
<dael> chris: Other cases where users can come up with thier own values and map with @font-face, but that's a lot of complexity. Maybe allow it to be an @font-face and define it there...not sure. Worried about too complex
<dael> myles: Agree. Worried about making this really complicated.
<dael> myles: I think there are a couple different @rules that apply to a font-family by name. If this is a problem here it's for the other like font-feature-values
<dael> chris: Yeah, exactly. That one too
<dael> myles: Another point, there can be different items in source list and you could want this specific to an item in the source list, but that's crazy. This is finding the right line in the middle
<dael> chris: If you do silly things you get strange results.
<dael> myles: That's my thought
<dael> astearns: Proposal is to close this no change?
<dael> myles: I could add normative text
<dael> myles: that makes it clear each of these are applied to each @font-face that share a family name. There's 2 parts and part 1 is I'm confused part 2 is is valuable. Part 2 we said no so let's describe
<dael> astearns: An example of how things can go wrong would be good
<dael> myles: Sure
<dael> astearns: Prop: Add normative text describing this issue and being more clear about how this all works with an example for how things can go terribly wrong
<fantasai> sgtm
<dael> astearns: Objections?
<dael> RESOLVED: Add normative text describing this issue and being more clear about how this all works with an example for how things can go terribly wrong