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

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`

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

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 3 July 2018 06:36:33 UTC