[css-color-5] Clarification needed on type of r, g, b constants in "relative color syntax" for rgb()

[weinig]

In CSS Color 5's Relative color syntax, https://drafts.csswg.org/css-color-5/#relative-RGB, the spec is inconsistent on the types/semantics for the r, g, and b, constants. The normative text says "r", "g", and "b" are percentages ("r is a that corresponds to the origin color’s red channel after its conversion to sRGB"), but in Example 13, it is intermixing them with non-percentages:

    rgb(from indianred 255 g b)

It seems like this should resolve to

    rgb(255 36.0784% 36.0784%)

which is invalid.

In the investigative implementation in WebKit, to keep the example working, I implemented it to assume that "r", "g", and "b" can either be numbers or percentages, but they all have to be the same and match the constants as well. So in the example above, since the first parameter is 255, it forces "g" and "b" to use their numeric forms, and therefore resolves to:

    rgb(255 92, 92)

Which is what the example says is the result.

This leaves a weird case of no numeric constant being used for any parameter, like:

    rgb(from indianred calc(r+1) calc(g+1) calc(b+1))

in which case we need some default type. I have picked percentages, since that is what the spec text currently says is the type, but I am not sure if that is desirable.

[tabatkins]

A few days ago I pushed some significant edits cleaning up that section of the spec; it looks like the issue preventing the latest version from displaying on the drafts server has been fixed, so the cases you're asking should be answered now.

In particular, I tweaked how the rgb() function handles its relative form, allowing mixed numbers and percentages, precisely so that the example you're citing would actually work (because I think it should). (Absolute syntax still requires you to pick one or the other and use it for all three components.)

rgb(from indianred calc(r+1) calc(g+1) calc(b+1))

This would be invalid, however, since the channel keywords are always percentages. We can't have values whose types depend on unification with the rest of the expression; or at least, I'm not willing to write a spec for type unification in CSS more than we currently do. ^_^

(I also fixed the specification wrt the h keywords - they're now properly angles, not numbers - and adjusted the examples to match.)

[LeaVerou]

Just as an FYI, after #5782, we are thinking of axing this entire syntax in favor of functions to get component values which are a) closer to what authors are already using in preprocessors and b) allow for vastly more use cases, as they enable use cases where components are combined from multiple colors (previously awkwardly handled by color-mix() with adjusters).

@tabatkins While these edits are most likely welcome (I haven't checked with @una @svgeesus and @argyleink), could you please give a heads up to the editors of specs you modify so that we know what's going on without having to look at the entire commit history? Even better, please discuss any substantive edits with us first?

[samweinig]

Just as an FYI, after #5782, we are thinking of axing this entire syntax in favor of functions to get component values which are a) closer to what authors are already using in preprocessors and b) allow for vastly more use cases, as they enable use cases where components are combined from multiple colors (previously awkwardly handled by color-mix() with adjusters).

Very cool.

[tabatkins]

@tabatkins While these edits are most likely welcome (I haven't checked with @una @svgeesus and @argyleink), could you please give a heads up to the editors of specs you modify so that we know what's going on without having to look at the entire commit history? Even better, please discuss any substantive edits with us first?

While it was a decent editorial edit, mechanically it wasn't substantive. I was just fixing some errors and doing one minor change to rgb() to make it actually match with the examples.

[astearns]

While it was a decent editorial edit, mechanically it wasn't substantive. I was just fixing some errors and doing one minor change to rgb() to make it actually match with the examples.

Let’s add decent editorial edits to the list of things that should require editorial review, then.