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