[css-values] New units for <percentage> based on existing usage

[Crissov]

<percentage> can be used interchangeably in some places with other numeric notations. In other properties, unitless numeric notation is used exclusively although it looks and works a lot like percentages. I propose that this be generalized and harmonized.

• font-weight before Level 3 had "numeric keywords" 100, 200 through 900 and now accepts an integer number with one to three digits, [1, 1000].
• some <color> components, in particulkar inside color(), can be provided as floating point numbers in the range [0.0, 1.0], either specified as <number> or as <number-percentage>
• sRGB <color> components can be provided as integer numbers in the 8-bit (i.e. 1-byte) range [0, 255], optionally in hexadecimal notation [00h, FFh]
• sRGB <color> components can be provided as hexadecimal integer numbers in the 4-bit (i.e. 1-nibble) range [0, F], i.e. [0, 15], although this is only supported in three- and four-char hexcodes and not in common functional notation
• font-feature-settingsand similar oney kind of accept integers as boolean values in the range [0, 1], i.e. out of the set {0, 1}

In order to accommodate 10-bit and 12-bit color channels, the byte integers are to be relaxed to become floating point numbers. Alternatively, they would have needed some way to represent the ranges [0, 1023] and [0, 4095], respectively. #480

I propose that we treat all of the cases mentioned above as special cases where it is allowed to omit the unit, as it is for deg in <hue>s. They would thus become special cases of the <percentage> value type. Therefore, we would need units for them elsewhere. Here is a first suggestion:

• pm, per mille (‰) for <font-weight>: [0, 1000]
• u, unity: [0.0, 1.0]
• b or byte, byte: [0, 255]
• h, hex hexadecimal or n nibble: [0, 15]
• k, kibibit: [0, 1023]
• t tribble or perhaps w, word: [0, 4095]
• bool, boolean: [0, 1] (true and false global keywords are a non-starter)

The following examples would become valid then:

• color: rgba(50%, 0.5u, 500pm, 7h);
• color: rgb(127b, 1023k, 2047t);
• font-weight: 50%;

[tabatkins]

Per usual for these suggestions, while we could add any number of units, we're only going to add things with demonstrated actual need, or a pretty compelling argument that there's a currently-unaware desire for the unit that would make things a lot easier for people once they started using it.

Do you have any demonstrated user need, or reasonable arguments for a currently-unaware need that would be very useful once people were aware of it, for any of these?

[Crissov]

This proposal, obviously, is not about new features and only tangentially about an improved authoring experience. It would help to make future additions to CSS better if numbers were always followed by a unit unless they are counting something. If in one place or another it is commonplace to omit a particular unit and <number> is not used for counts, then it could be recorded in the definition of the respective property or function which unit is implied if none is present. There are, for instance, cases of deg and px being implied, while % is never implied (unlike *u above).

We do not need to have issues like #5547, #4648, #4874, #4477, #3450, #3399, #3342, #2690, #2341, #872, #635, #573, #278 and #272 over and over again. #250, #646, #1463 and #2789 are also related.

For what it’s worth, though, I don’t think there’s a strong case to be made for *h, *k and *t.

[tabatkins]

Unit implication is a legacy bug; we don't propagate it into new things. It makes various other bits of the platform confusing.

[Crissov]

Exactly. I'm not suggesting to introduce more cases of implied units, but to make the existing (and possibly future) cases more systematic and thus hopefully less confusing.

[tabatkins]

While expressing the range of number values directly in a unit has some potential worth, we don't have any compelling evidence that this is a problem for authors in practice. Our naked numbers that are indicating a value in a range (rather than just counting something) are all 0-1 ranges, outside of font-weight (0-1000) and color functions (0-255 for rgb(), and 0+ for lab()), and it doesn't seem that there's any particular desire on authors' part to use those ranges interchangeably.

So, I'm closing this no change. Let me know if this is acceptable.

[Crissov]

Just for the record: most color components can now be specified as a percentage and have a percent reference range specified in CSS Color 4 to enable legacy numeric notation used outside CSS, e.g. [0%, 100%] <=> [0, 100] for L, [0%, 100%] <=> [0, 150] for C and [-100%, 100%] <=> [-125, 125] for a and b in CIELAB, but [0, 1], [0, 0.4], [-0.4, 0.4], respectively, in OKLAB.
This issue argued against introducing arbitrary limits like 125, 150 and 0.4 seen here, but did not provide solutions for these specific, seemingly random ones – it would only have provided u for OK lightness.