Re: [csswg-drafts] [fonts-4] @font-palette-values uses illegal integer descriptor names

The CSS Working Group just discussed `@font-palette-values uses illegal integer descriptor names`, and agreed to the following resolutions:

* `RESOLVED: Descriptors will be called color-nnn`
* `RESOLVED: define family without leading 0s`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: @font-palette-values uses illegal integer descriptor names<br>
&lt;dael> Github: https://github.com/w3c/csswg-drafts/issues/1523<br>
&lt;dael> Chris: Is Myles on?<br>
&lt;dael> TabAtkins: I can summerize the issue I think<br>
&lt;dael> TabAtkins: THis is about numeric descriptiors? Yeah. Per css syntax you can't have numeric property names. It's not nec. a problem to change, but it's not 100% clear we want to vs using a name that is an ident.<br>
&lt;dael> TabAtkins: I don't have storng opinions, but this doesn't parse successfully right now.<br>
&lt;dael> Chris: There was discussion on that earlier today. Suggestion is...the thing that says the number of pallant entries is a [missed] Is there a way to declare the pattern?<br>
&lt;Chris> s/[missed]/uint16<br>
&lt;dael> TabAtkins: Same as custom prop. Defining a family of descriptors is what's needed here. There's no way around that.<br>
&lt;dael> Chris: Could you give the syntax for that?<br>
&lt;dael> TabAtkins: It's not anymore tricky than variables where I say use the pattern for the name. --* where * is anything following restrictions. It's a number* and we put in restrictions and prose.<br>
&lt;dael> TabAtkins: That's orthogonal because no matter what we need to accept an arbitrary # of descriptors. However, current syntax per spec doesn't parse.<br>
&lt;dael> Chris: That's the worst problem. I'm assuming no one is arguing to change syntax for numbers. I've seen people argue against htat.<br>
&lt;rachelandrew> re: author feedback I think it is hard to get feedback on stuff if authors can't think up a use case for the thing - I'd write about the fallback alignment but I've not come up with a situation where I might end up in that situation. I try and write these things so people think " I might need to do that and here is a problem I can see".<br>
&lt;dael> TabAtkins: Myles says leave as number and change syntax spec. That's fine, but it needs to have full agreement of impl. Or should we go back and say make these an ident family instead of a number family.<br>
&lt;dael> TabAtkins: I want syntax approved by a wider set of people.<br>
&lt;dael> Chris: Which way do we want to go with this? I don't think Myles was against renaming descriptors. It's more combersome but eh.<br>
&lt;dael> leaverou: How about we step back and think if those are good names for the descriptors. I think something like color1...<br>
&lt;fantasai> s/color1/color-1/<br>
&lt;dael> TabAtkins: I agree. I don't think the numbers are very good either. color1 is more explicit.<br>
&lt;dael> leaverou: And seems reasonable to reserve int for something more substantial.<br>
&lt;dael> Chris: I'm hearing an argument against raw int. Does anyone like/dislike color-n?<br>
&lt;dael> fantasai: I'm in favor for the readability arg/ from le<br>
&lt;dael> leaverou:<br>
&lt;dael> Chris: Obj?<br>
&lt;dael> Chris: I see IRC support<br>
&lt;dael> RESOLVED: Descriptors will be called color-nnn<br>
&lt;leaverou> s/color-nnn/color-&lt;integer>/<br>
&lt;dael> fantasai: What about leading 0s?<br>
&lt;dael> Chris: If it's int you could put it in hex I guess. We don't a thing where color-1 and color-01 are different.<br>
&lt;dael> Chris: TabAtkins is there a problem?<br>
&lt;tantek> interesting. because color:#1; color:#01; color:#001 are all different :P<br>
&lt;tantek> just saying, not theoretical<br>
&lt;dael> TabAtkins: Depends. Easier if we define that the family of prerpteis is int without leading 0s. IT's possible to do the other way. It's not a huge deal to discared extra digits. It seems like that would make it more annoying in a theoretical prospective. Other places with family we comapre on exactness.<br>
&lt;leaverou> tantek: Indeed. #1 and #01 are invalid<br>
&lt;dael> Chris: I like canonical. I prefer we say waht the canonical form personally.<br>
&lt;dael> Chris: Other views?<br>
&lt;tantek> leaverou: meh, they do stuff in browsers :P<br>
&lt;dael> fantasai: If you have canonical it has no leading 0s.<br>
&lt;dael> Chris: Exactly<br>
&lt;dael> plinss: It would prob sort badly.<br>
&lt;leaverou> tantek: Not in CSS.<br>
&lt;dael> Chris: Correct.<br>
&lt;fantasai> s/0s/0s because we don't know how many 0s to use/<br>
&lt;dael> Chris: Is there a use case to sort descriptors? They might type in odd orders so they override. So it's reasonable they should append.<br>
&lt;dael> plinss: I'm not overly concerned. Hand authors won't be concerned. It's tooling.<br>
&lt;dael> TabAtkins: It also depends on you have at least 10 values. Most palattes are smaller.<br>
&lt;dael> Chris: That's correct.<br>
&lt;dael> Chris: That we've seen so far anyway.<br>
&lt;dael> TabAtkins: It's a mtter of tooling and they can aprpover<br>
&lt;dael> Chris: Obj?<br>
&lt;dael> RESOLVED: define family without leading 0s<br>
&lt;dael> Chris: Should we leave room for Myles to object?<br>
&lt;dael> TabAtkins: Yes, absolutely. Myles should feel free to object since he's not here.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1523#issuecomment-322825719 using your GitHub account

Received on Wednesday, 16 August 2017 16:24:53 UTC