Back-porting the mixed <number> and <percentage> color component syntaxes to CSS Color 4

[svgeesus]

This was already proposed and discussed in passing, in the context of a CSS Color 5 issue, but I wanted to break it out into a separate issue to be sure no-one missed it.

Relative Color Syntax in CSS Color 5 allows mixing <number> and <percentage>. But currently, this is only allowed for RCS; if you miss out the from <color> then you have to use all-numbers or all-percentages for the color components.

Here is a quote from a WPT test:

    // Testing mixes of number and percentage. (These would not be allowed in the non-relative syntax).
    test_valid_value(`color`, `rgb(from rebeccapurple r 20% 10)`, `rgb(102, 51, 10)`);
    test_valid_value(`color`, `rgb(from rebeccapurple r 10 20%)`, `rgb(102, 10, 51)`);
    test_valid_value(`color`, `rgb(from rebeccapurple 0% 10 10)`, `rgb(0, 10, 10)`);
    test_valid_value(`color`, `rgb(from rgb(20%, 40%, 60%, 80%) r 20% 10)`, `rgb(51, 51, 10)`);
    test_valid_value(`color`, `rgb(from rgb(20%, 40%, 60%, 80%) r 10 20%)`, `rgb(51, 10, 51)`);
    test_valid_value(`color`, `rgb(from rgb(20%, 40%, 60%, 80%) 0% 10 10)`, `rgb(0, 10, 10)`);

This seems silly, and so I said:

Also tempted to back-port the "accept a mixture of <number> and <percentage>" to CSS Color 4. I believe this already has tests in WPT (because people are implementing CSS Color 5 and 4 at the same time).

To be clear, this would affect the modern syntax only, not the legacy syntax.

Also to be clear, people can get this mixing already, if they really want, simply by not actually using the origin color:

rgb(from black 50% 75 127)

I am proposing to make those simplifying edits and then to change the relevant portions of WPT tests such as color-invalid-rgb so that previously invalid combinations get moved over to the valid tests.

[svgeesus]

Related:

• [css-color-5] Allow use of 0 with <percentage> color components #7338
• [css-color-4] rgba() is legacy so does not support none. Right? #7900

[svgeesus]

@GPHemsley said in response to the proposal:

This is food for thought, as is @cdoublev's suggestion. Implementations could be simpler if they didn't have to branch for all the different, mutually-exclusive syntaxes.

[svgeesus]

In a different issue, @SebastianZ said:

But maybe someone could make an HTTP archive query to check whether there are currently usages of number and percentage mixtures (that currently break but would work after that change and cause a visual difference).

At least tools like VS Code obviously already support mixing numbers and percentages. And SCSS and PostCSS just pass them through without errors.
So the Web ecosystem seems to be already prepared for that. And if there are tools that don't allow mixing both, they can adjust easily.

[svgeesus]

VSCode already supports this :)

The browsers do not.

[svgeesus]

The browsers do, however all support modern syntax rgba() (with either <number> or <percentage>, not mixed)

[svgeesus]

Now done.

[cdoublev]

I am sorry to open discussions in different issues that are all related to back-porting mixed <number> and <percentage> to CSS Color 4, but this issue seems definitely appropriate for asking the following questions.

Can you please clarify the range to resolve <percentage> to <number> when it represents saturation/lightness in hsl() and hsla()? 0% resolves to 0 and 100% to 1? Chrome/FF do not support <number> for these components, as expected by WPT.

You did not back-ported mixing <number> and <percentage> in hwb(). I do not know if this was intentional but the same question applies to resolve <percentage>, which is allowed in CSS Color 5. But I am off topic here... so let's continue! =)

For custom color spaces, specified component values less than 0 or 0%, or greater than 1 or 100% are not invalid; they are clamped to the valid range at computed value time.

This seems to enforce <percentage> to resolve in [0,1] for custom color profiles, whereas <percentage> resolves to different ranges in other color functions, depending on the component.

I may have missed how to resolve <percentage> in CSS Color 5, when the target range is not defined in CSS Color 4. Otherwise, this question can be discussed in a separate issue, if you prefer.

[svgeesus]

I am sorry to open discussions in different issues

It is fine; the specs benefit from your careful review and comments.

You did not back-ported mixing and in hwb(). I do not know if this was intentional

My mistake. hwb() doesn't have a legacy syntax, and hwb() was not mentioned in the CSWG resolution, but RCS hwb() does allow mixing <number> and <percentage> so I should have back-ported it.

[cdoublev]

Can you please clarify the range to resolve <percentage> to <number> when it represents saturation/lightness in hsl() and hsla()? 0% resolves to 0 and 100% to 1?

There is some confusion in my questions because hsl() and hwb() resolve to rgb() and the conversion algorithm takes the percentage value, therefore the relevant question is what must be the range of <number> in hsl() and hwb(): [0,1] or [0,100]?

Thanks for the follow up.

[svgeesus]

Follow-on change from the back-port: this is no longer correct:

Except as specified for individual color functions, (for example, HWB Whiteness and Blackness return <percentage>), the channel keywords return a <number>; if they were originally specified as a or an <angle>, that <percentage> is resolved to a <number> and the is resolved to a <number> of degrees (which is the canonical unit) in the range [0, 360].

because W and B now accept number, so per CSSWG resolution the w and b channel keywords will now return a <number>.

So that will become simpler:

The channel keywords return a <number>; if they were originally specified as a or an <angle>, that <percentage> is resolved to a <number> and the is resolved to a <number> of degrees (which is the canonical unit) in the range [0, 360].

[svgeesus]

There is some confusion in my questions because hsl() and hwb() resolve to rgb() and the conversion algorithm takes the percentage value, therefore the relevant question is what must be the range of <number> in hsl() and hwb(): [0,1] or [0,100]?

[0,100].

From CSS Color 4 HSL Colors: hsl() and hsla() functions:

Percentages Allowed for S and L
Percent reference range for S and L: 0% = 0.0, 100% = 100.0

and from HWB Colors: hwb() function:

Percentages Allowed for W and B
Percent reference range for W and B: 0% = 0.0, 100% = 100.0

[svgeesus]

Leaving open until the test cases are updated

[svgeesus]

Closing this (and other issues where no change to the spec is expected).