[css-color-5] Allow use of 0 with <percentage> color components

[SebastianZ]

In w3c/fxtf-drafts#456 it was noted that the examples in Compositing 2 were wrong. The reason for that was that CSS Color 4 doesn't allow to mix <number> and <percentage> values for color components.

This is generally ok as mixing those two types of values doesn't make sense here, though in case of 0 as value this seems unexpected. People expect 0 and 0% to be exchangable.

E.g. currently rgb(100% 0 0 / 50%) is currently invalid and needs to be written as rgb(100% 0% 0% / 50%) for this reason.

Therefore, I suggest to allow combining unitless 0 values with percentages in all color functions.
Or, they could even be allowed generally for all places that take <percentage> values.

Sebastian

[svgeesus]

This is due to the historical use of 0..255 integers in rgb(). When we wanted to add a bit-depth-independent way to specify the RGB components, we leant on percentages. But we required you to use all one or all the other. So nothing like

rgb(17.5% 127 54.8%) for example.

I agree that this collides with the user expectation that 0% and 0 mean the same thing.

At this point these are both legacy syntactic forms.

Even in CSS Color 5, relative color syntax does allow you to mix numbers and percents but only with the relative color syntax; the historical forms we left untouched.

I guess the questions to ask are:

• is it worth fixing this for 0 and 0% particularly?
• is it worth fixing this for mixed numbers and percents generally
• if so, how does this affect the computed value and serialization?

I suspect that lots of in-the-wild script to manipulate color is likely to break if number and percent can be freely mixed.

[svgeesus]

Also re-tagging to CSS Color 5, as Color 4 is firming up for Candidate Recommendation

[fantasai]

(Untagging css-values-4 as we cannot make this allowance generally across CSS.)

[tabatkins]

Yeah, we absolutely cannot allow unitless percentages in general; width: 0% has very different behavior from width: 0px when the container has indefinite available width.

While the color syntaxes don't have a similar issue (their use of %s are relative to fixed reference values, rather than a contextual one), I don't see a good reason to allow 0, specifically, to intermix with percentages. I'd rather just relax the grammar to allow any mixture of numbers and %s across the arguments. I'm not sure why the spec required them to be all one way or the other, as that restriction doesn't do anything productive.

[svgeesus]

I'm not sure why the spec required them to be all one way or the other, as that restriction doesn't do anything productive.

Because that is what CSS1 did.

So there is an assumed Web compat issue (what content does, what scripts expect, what browsers implement since forever), although given other changes like the 0..255 form now allowing <number>, removal of commas, and addition of none it isn't clear that this is a strong argument.

[SebastianZ]

Yeah, we absolutely cannot allow unitless percentages in general; width: 0% has very different behavior from width: 0px when the container has indefinite available width.

I wasn't aware of that. So yeah, then we can't generalize unitless percentages.

I'd rather just relax the grammar to allow any mixture of numbers and %s across the arguments.

So there is an assumed Web compat issue (what content does, what scripts expect, what browsers implement since forever), although given other changes like the 0..255 form now allowing , removal of commas, and addition of none it isn't clear that this is a strong argument.

I'd be fine to relax the syntax to allow mixtures of numbers and percentages to cover the described use case (even when it looks a bit weird to me mixing numbers besides 0 with percentages).

@svgeesus As you say, there were already a lot of other more disruptive changes to the syntax. So I don't think that's a big issue. 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.

Sebastian