[css-fonts-4] [color fonts] Ability to choose palette and colors by predefined name

[RoelN]

Regarding 7.1. Controlling Color Font Palettes: The font-palette property, fonts with a CPAL table will be able to give custom names to palettes and their colors. See Palette Labels and Palette Entry Label in the OpenType spec.

If a font comes with a palette called "Toxic Green", would you be able to say font-palette: 'Toxic Green';? Or inside a @font-palette-values query say base-palette: 'Toxic Green';?

Overwriting colors would have to happen similarly, I suppose. So instead of (or along with)

@font-palette-values Augusta {
  font-family: Handover Sans;
  base-palette: 3;
  1: rgb(43, 12, 9);
  3: var(--highlight);
}

you should be able to do

@font-palette-values Augusta {
  font-family: Handover Sans;
  base-palette: 'Toxic Green';
  'Main fill': rgb(43, 12, 9);
  'Outline': var(--highlight);
}

where "Main fill" and "Outline" are entries in the Palette Entry Label table of the font.

[litherum]

Using strings from font files is pretty scary because of the regionalization inside the font file. (You really don't want your website to work fine in one country but not in another). Historically, we've stayed away from using these strings, so we should be careful if we want to start using them now.

[css-meeting-bot]

The Working Group just discussed choosing palette and colors by predefined name in fonts, and agreed to the following:

• RESOLVED: adopt the mutli-value descriptor font font-face

The full IRC log of that discussion

<fantasai> Topic: choosing palette and colors by predefined name in fonts
<fantasai> github: https://github.com//issues/1125
<frremy> chris_: color fonts are required to use a palette, svg fonts can
<frremy> chris_: initially, these were just indexes in an array
<frremy> chris_: but in the new version, you can name palettes
<frremy> chris_: you can even name specific values of a palette
<frremy> chris_: so authors would probably want to use these names in their css
<frremy> chris_: (it is localized so we will need to accept match for any of the localizations)
<dbaron> I wonder if there's a requirement that you can't use the same name for English for pallette 2 and for Spanish for pallette 4. (I'm reminded of Indonesia's timezone abbreviations...)
<frremy> chris_: one good reason for this, is that if you upgrade to a new version of the font, palettes might have another index, but the palette names will remain the same
<frremy> astearns: so if you use the english name, it will match also on a chinese pc?
<frremy> myles: yes, that seems like a requirement
<frremy> myles: we already do that for font-family
<chris_> CPAL specification https://docs.microsoft.com/en-us/typography/opentype/spec/cpal
<frremy> florian: I agree
<frremy> heycam: you could specify a set of names
<frremy> heycam: what if the font use a same name for different languages for different palettes?
<frremy> myles: that seems like an error
<frremy> myles: I propose to use the first one in the font file
<frremy> myles: (there is an order in the font file, we can use that)
<frremy> dbaron: (disgression on indonesian timezones)
<frremy> astearns: are these color palettes going to be descriptor only?
<frremy> chris_: only needed when you override font-color-palette values
<frremy> myles: there is no property, its only for the specific at rule
<frremy> chris_: how do we do this syntax change backward-compatible?
<frremy> myles: we should ask TabAtkins
<frremy> myles: but we could make this work
<frremy> (TabAtkins is currently away, will be back shortly)
<frremy> heycam: do we have examples where we use identifiers instead of strings other that font-family
<frremy> ?
<frremy> heycam: we could just accept strings only, maybe?
<frremy> myles: there are two levels of name
<frremy> chris_: one for the palettes, and one for the names of values inside the palette
<frremy> myles: so we would need to restrict to some values
<frremy> astearns: but fonts can do whatever, right?
<frremy> myles: right, but why would you?
<frremy> heycam: but you can escape in css, so it's fine
<frremy> astearns: can descriptors be strings though?
<frremy> myles: maybe, sure wish TabAtkins was here
<frremy> emilio: that seems annoying to implement
<frremy> emilio: (too faint to minute)
<frremy> emilio: can we use a new at-rule?
<frremy> heycam: question about the example in the spec:
<frremy> heycam: what if a palette was named "font-family"
<frremy> myles: yes that would be a problem
<frremy> chris_: that's why we proposed to use strings
<frremy> myles: we could restrict to color-<ident>
<frremy> dbaron: which then doesn't require to change what is allowed to be parsed
<frremy> myles: how about `colors-"abc"`:?
<frremy> dbaron: that seems to defeat the purpose of the previous resolution
<frremy> myles: we can also resolve to remove this at-rule thing
<frremy> heycam: I'm fine with it in theory
<frremy> frremy: but why not use idents, you can type any code point
<frremy> dbaron: the advantage of strings is that they are syntaxically different
<heycam> s/with it/with strings or integer on the LHS of the colon/
<frremy> emilio: if we allow arbitary identifiers, then we cannot extend that at-rule in the future
<dbaron> q+ to mention developer confusion with identifiers and strings
<frremy> myles: yes, I think strings are better
<frremy> myles: but then why not do this for numbers too?
<frremy> heycam: I didn't like the way we resolved this for svg
<frremy> florian: are we going to break preprocessors with this though?
<heycam> s/svg/svg glyphs, where we have --color0 etc./
<astearns> ack dbaron
<Zakim> dbaron, you wanted to mention developer confusion with identifiers and strings
<frremy> fantasai: preprocessors should follow the rules for error handling of css, and leave things as-is
<frremy> dbaron: developers who started using font-family will be annoyed that things will be different here
<frremy> chris_: ah, tab is there, maybe he can prevent us from breaking css
<frremy> astearns: (explain to tab the proposal "abc":"def")
<fantasai> https://drafts.csswg.org/css-fonts-4/#font-palette-values
<frremy> myles: (continue to re-explain this further)
<frremy> TabAtkins: that would require changes to the parser
<frremy> TabAtkins: it's not a big change
<frremy> TabAtkins: numbers however not, because "3" vs "3e1" etc
<frremy> florian: what about preprocessors
<frremy> TabAtkins: it could work
<frremy> TabAtkins: if you really want to do this, I'm fine with it
<frremy> myles: the alternative is something like "font-feature-settings"
<frremy> chris_: (jokingly) we could allow full json
<frremy> myles: what do you think, what would be better?
<frremy> myles: the "desciptor: "abc" "value"; descriptor: "def" "value";
<frremy> myles: or "abc":"value"; "def":"value"
<frremy> florian: that big string is annoying to deal with
<frremy> TabAtkins: css typed om will fix that
<frremy> TabAtkins: and since you dont need to cascade, I find that more idiomatic
<frremy> heycam: the only thing I don't like the with the repeat syntax is that descriptors usually override each other
<frremy> frremy: that wouldn't be the first time we want to change that
<frremy> myles: but we wouldnt want to build this on additive css because we want this sooner
<frremy> frremy: wasn't my proposal, just saying this change will happen anyway at some point
<frremy> myles: (repeats the two proposals)
<frremy> TabAtkins: the latter is more idomatic
<frremy> florian: I like it better
<frremy> frremy: me too
<frremy> heycam: what about the cssom argument?
<frremy> TabAtkins: this is legacy
<TabAtkins> override-color: [ [ <string> | <integer> ] <color> ]#
<frremy> astearns: I'm hearing consensus on that proposal
<frremy> astearns: any objection to that idea?
<frremy> myles: we should bikeshed the name though
<frremy> astearns: what if there is an invalid pair in the list?
<frremy> myles: same thing we would do for font-feature-settings
<frremy> astearns: happy with that
<frremy> heycam: but doesn't font-feature-settings only allow a set of predefined values?
<frremy> myles: no, there are a few predefined ones but font authors can defined their own
<frremy> fantasai: let's use the same syntax as font-feature-settings
<frremy> florian: that seems like the same to me
<frremy> florian: except that the value is a color not a number
<frremy> astearns: ok, any objection?
<frremy> myles: we would rescede the previous resolution about "colors-<int>"
<frremy> RESOLVED: adopt the mutli-value descriptor font font-face

[svgeesus]

@font-palette-values Augusta {
  font-family: Handover Sans;
  base-palette: 'Toxic Green';
  override-color:  
    'Main fill' rgb(43, 12, 9),
    'Outline' var(--highlight),
    5 papayawhip;
}

New override-color takes a comma-separated list of palette index specifiers (strings, or numerical indexes) and colors. This avoids having strings as descriptor names.

Same rules for duplicates as font-feature-settings.

[tabatkins]

Grammar, for completeness: [ [ <string> | <integer> ] <color> ]#. @litherum doesn't like 'override-color', so use whatever they decide they like better. ^_^

[litherum]

I don’t dislike the name.

[RoelN]

Thanks for the work, everyone! 🍰

I don't know if it's important, but it feels kinda weird to always be overriding something existing when applying your own. I guess it'd work, but if you want to set all three colors of Bixa Color it feels weird to first have to appoint some random existing palette:

@font-palette-values BixaGreen {
  font-family: Bixa Color;
  base-palette: 'Hot pink'; /* completely irrelevant */
  override-color:  
    1 green,
    2 limegreen,
    3 palegreen;
}

Maybe when setting a custom palette not based on another, you could set base-palette: none or leave out base-palette altogether (where all colors could default to currentColor).

Some name bikeshedding: would it be in alignment with other CSS like border-color, background-color etc. to call it palette-color? Or maybe simply layer-color? It wouldn't be stressing the overriding so much.

[litherum]

We should probably say something like “if no base-palette is specified, the 0’th palette is used”, and “if base-palette refers to a palette that doesn’t exist, then the @-rule is only valid if all 0-n colors are specified, where n is the number of colors in a palette for this font”

[svgeesus]

“if base-palette refers to a palette that doesn’t exist, then the @-rule is only valid if all 0-n colors are specified, where n is the number of colors in a palette for this font”

perhaps more robustly,

“if base-palette refers to a palette that doesn’t exist, then unspecified palette index entries are set to currentColor”

or transparent or black or whatever. But filled with a default, rather then the new palette being discarded.

Maybe when setting a custom palette not based on another, you could set base-palette: none or leave out base-palette altogether (where all colors could default to currentColor).

Omitting/setting to none would not then allow you to actually use the shiny new palette, in the font-palette property. So the 'Hot pink' in the example above is not irrelevant.

So how about: if the palette index is greater than the number of predefined palettes; or if the palette name does not match, then a new palette is created. Or to state it another way, @font-palette-values creates a palette which is initialized to currentColor, except if it is overriding an existing palette in which case it is initialized to the values from that matching palette. The explicitly specified palette index entries are applied.

[RoelN]

Omitting/setting to none would not then allow you to actually use the shiny new palette, in the font-palette property. So the 'Hot pink' in the example above is not irrelevant.

Why not? I'd refer to it by "BixaGreen" there, right?

[litherum]

Right. You’d refer to it by the ident between the @ and the {