[fonts-4] @font-palette-values uses illegal integer descriptor names

[tabatkins]

As currently defined, @font-palette-values uses some integer descriptor names (to override the colors of particular indexes in the palette). However, per Syntax, declaration names are restricted to idents only.

Do we want to change @font-palette-values to use idents, probably with a prefix before the integer, or do we want to modify Syntax to allow integer names for declarations? (We shouldn't allow float names, as comparisons become fraught at that point.)

(For example, does 01: red; work? Does it have the standard "last declaration with a given name wins" behavior if there's also a 1: blue declaration in the block?)

[litherum]

I don't know of any reason to disallow integer names for declarations. Prefixing a number with 0 makes me think it's an octal number.

[tabatkins]

I don't know of any reason to disallow integer names for declarations.

Because it's currently illegal, per Syntax, and will result in those declarations being thrown out as syntax errors. ^_^

Prefixing a number with 0 makes me think it's an octal number.

That seems irrelevant? The question is what happens when people do it, not what you might interpret it as. (CSS is extremely clear that 05 is just the integer 5.)

If we want to allow integer declaration names, we have to answer some questions about how they're compared.

[litherum]

You misunderstand me.

When I say "I don't know of any reason to disallow integer names for declarations" I mean "I don't know of any reason why Syntax should consider integer names for declarations as illegal"

When I say "Prefixing a number with 0 makes me think it's an octal number" I mean "Requiring prefixing these numbers with 0 is problematic for authors because this number format is already overloaded in other contexts."

[tabatkins]

I didn't suggest "requiring prefixing these numbers with 0". That would indeed be crazy.

I'm saying that, if we change Syntax to allow integer declaration names, we need to answer the question of what this means:

@font-palette-values foo {
  1: blue;
  01: red;
}

Is the second one illegal? (It would be very difficult/weird to make it illegal.) If they're both legal, do they represent the same descriptor, or different ones? (For the same reason, difficult/weird to make them different descriptors.) If they're the same descriptor, it seems possibly confusing to authors that two declarations with different names written down are actually the same; in all existing declarations, the names are compared codepoint-by-codepoint, possibly with ASCII case-folding.

I'm not necessarily opposed to this, but we do need to define it one way or another in Syntax. Or we can define the names to be index-1/etc, making the names more descriptive and removing the need for any additional changes in Syntax and browser parsers.

[litherum]

Seems that they should both be legal, and they represent the same descriptor (so the "red" one would override the "blue" one). I don't think there will be much confusion about this situation because it's likely to be rare and because it is intuitive.

[tabatkins]

So now we come back to my final question: are integer names important enough to justify changing the Syntax spec, versus using a potentially more-descriptive set of names like index-1?

[svgeesus]

Numeric descriptors seem overly generic (but each says to which at-rule it applies, so I guess other at-rules could also have any numeric descriptors they need).

OTOH having to use some prefix just to get around the rules of the language is a pain. Remember the restriction that IDs could not start with a number, so people who cared about validity had to change id="6" to id="i6" or whatever? Despite the fact that the numeric IDs worked just fine in practice. An annoyance which HTML5 fixed, of course.

This seems like the same sort of thing, to me.

[LeaVerou]

This seems like two separate issues to me:

1. Should we change Syntax to allow for integer descriptors?
2. Should the @font-palette-values descriptors be raw integers?

IMO, the answers are Yes and No respectively. Integer descriptors could prove useful in the future, so they should be allowed. However, in the large scheme of things, @font-palette-values is a relatively minor feature and we shouldn’t waste such a useful syntactic construct on it. I don’t see why we can’t prefix these properties with something like color-. It makes the rule easier to read and the verbosity doesn’t really get in the way, since this is not something authors will type again and again.

[svgeesus]

I see that the OpenType spec call these color records so color-nnn is reasonable. How big should the nnn part be, though? numPaletteEntries is uint16 :) so if we aren't going to allow integers then do we need to declare 64k descriptor names? Or can they be defined as <name> "-" <number> ?

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: @font-palette-values uses illegal integer descriptor names
<dael> Github: https://github.com//issues/1523
<dael> Chris: Is Myles on?
<dael> TabAtkins: I can summerize the issue I think
<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.
<dael> TabAtkins: I don't have storng opinions, but this doesn't parse successfully right now.
<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?
<Chris> s/[missed]/uint16
<dael> TabAtkins: Same as custom prop. Defining a family of descriptors is what's needed here. There's no way around that.
<dael> Chris: Could you give the syntax for that?
<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.
<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.
<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.
<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".
<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.
<dael> TabAtkins: I want syntax approved by a wider set of people.
<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.
<dael> leaverou: How about we step back and think if those are good names for the descriptors. I think something like color1...
<fantasai> s/color1/color-1/
<dael> TabAtkins: I agree. I don't think the numbers are very good either. color1 is more explicit.
<dael> leaverou: And seems reasonable to reserve int for something more substantial.
<dael> Chris: I'm hearing an argument against raw int. Does anyone like/dislike color-n?
<dael> fantasai: I'm in favor for the readability arg/ from le
<dael> leaverou:
<dael> Chris: Obj?
<dael> Chris: I see IRC support
<dael> RESOLVED: Descriptors will be called color-nnn
<leaverou> s/color-nnn/color-<integer>/
<dael> fantasai: What about leading 0s?
<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.
<dael> Chris: TabAtkins is there a problem?
<tantek> interesting. because color:#1; color:#1; color:#1 are all different :P
<tantek> just saying, not theoretical
<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.
<leaverou> tantek: Indeed. #1 and #01 are invalid
<dael> Chris: I like canonical. I prefer we say waht the canonical form personally.
<dael> Chris: Other views?
<tantek> leaverou: meh, they do stuff in browsers :P
<dael> fantasai: If you have canonical it has no leading 0s.
<dael> Chris: Exactly
<dael> plinss: It would prob sort badly.
<leaverou> tantek: Not in CSS.
<dael> Chris: Correct.
<fantasai> s/0s/0s because we don't know how many 0s to use/
<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.
<dael> plinss: I'm not overly concerned. Hand authors won't be concerned. It's tooling.
<dael> TabAtkins: It also depends on you have at least 10 values. Most palattes are smaller.
<dael> Chris: That's correct.
<dael> Chris: That we've seen so far anyway.
<dael> TabAtkins: It's a mtter of tooling and they can aprpover
<dael> Chris: Obj?
<dael> RESOLVED: define family without leading 0s
<dael> Chris: Should we leave room for Myles to object?
<dael> TabAtkins: Yes, absolutely. Myles should feel free to object since he's not here.

[svgeesus]

So we resolved to have a bunch of descriptors running from color-0 to color-65535 with no leading zeroes. It looks as if the syntax module allows <number> to have a leading + or - though?
https://drafts.csswg.org/css-syntax/#consume-number

[tabatkins]

<number> is irrelevant here; color-* is an ident. The rule would just be that the name is color- followed by one or more digits, and the digits must have no leading zeros (unless it's the value color-0).

[litherum]

Why are we zero-indexing? src() fragment identifiers (representing items inside a TrueType Collection or a WOFF2 Archive) are one-indexed.

[litherum]

311174c

[astearns]

Why are we zero-indexing?

Should this be a separate issue?

[svgeesus]

src() fragment identifiers (representing items inside a TrueType Collection or a WOFF2 Archive) are one-indexed.

No, they aren't ^-^
See RFC 8081, section 4.2. Fragment Identifiers for Font Collections
https://tools.ietf.org/html/rfc8081#section-4.2

[svgeesus]

However, more relevantly, the OpenType spec is very clear:

Colors within a palette are referenced by base-zero index
https://docs.microsoft.com/en-us/typography/opentype/spec/cpal

[svgeesus]

Huh, while I am actually reading the spec; I said

So we resolved to have a bunch of descriptors running from color-0 to color-65535 with no leading zeroes.

which is wrong because

This special value does not change across multiple palettes. The maximum palette entry index is 65535 – 1, as the 65536th position is used in the COLR table to indicate the foreground font color.
https://docs.microsoft.com/en-us/typography/opentype/spec/cpal

[litherum]

Why are we zero-indexing?

Should this be a separate issue?

No, I don't have an opinion on this issue. If someone else wants to champion it, they can open it.

[litherum]

The fonts spec used to say:

If a container format lacks a defined fragment identifier scheme, implementations should use a simple 1-based indexing scheme

Then you modified it for #2205 to use PostScript name

[litherum]

631e449

[svgeesus]

Then you modified it for #2205 to use PostScript name

Yes. Well, Ken Lunde of Adobe (who knows a thing or two about Collections) told us the numerical-based fragment scheme would break on already-released fonts, so we (the IETF JustFont WG) changed the Internet Draft that became RFC 8081.

But yes, I then updated Fonts 3 so it conformed to RFC 8081.

However, the more important point in this discussion is that OpenType says the palette index is zero based and that modifiable values are in the range 0 to 0xFFFE.