Re: [csswg-drafts] [css-color-5] Behavior of `none` in relative color syntax (#10151)

> I took a weird turn somewhere and started imagining preserving `calc(none + 20)` resulting in `hsl(calc(none + 20) 50% 50%)` as the final value.

Er, yes, that _is_ the correct final value. Obviously, that is not useful by itself, but it becomes concrete once you interpolate.

> > The channel keywords return a `<number>`; if they were originally specified as a `<percentage>` or an `<angle>`, that `<percentage>` is resolved to a `<number>` and the `<angle>` is resolved to a `<number>` of degrees (which is the canonical unit) in the range `[0, 360]`.
> 
> But `none` is not a `<number>`.
> 
> [drafts.csswg.org/css-values-4/#numbers](https://drafts.csswg.org/css-values-4/#numbers)
> 
> So even if color space conversions preserve `none`, this section still requires a conversion to `<number>`, at which point `none` becomes `0`.

Yeah, we need to fix this in the spec, but I would consider it editorial.

> [drafts.csswg.org/css-color-5/#relative-syntax](https://drafts.csswg.org/css-color-5/#relative-syntax)
> 
> > However, if calculations are done on missing values, `none` is treated as `0`.
> 
> This is specifically for usage in math expressions.
> 
> These two phrases make it so that `none` always becomes `0` even if we agree that it should remain `none` as a result of color space conversion when possible therein.
> 
> I think that the first (typing as `<number>`) is simply an oversight and needs an extra clause to clarify that `none` at this stage isn't converted to `<number>`.

Yes.

> The second however is less simple. It requires defining what `none` means in math expressions.

Yes, it can be argued that the second is not editorial, though the _spirit_ of the prose has always been what I described above: the only reason to ever convert `none` to `0` is because you need to either convert the color to another color space where the dependencies between components are murky, OR you need to actually output it.

> For example it was recently added that `none` in `clamp` has a very specific meaning. This is very useful. I can also imagine stuff like `round(1.2, none)` having specific behavior.
> This is work that should be done for the css-values spec. Might be interesting to have specific handling of `none` at the various positions in math functions. Where the outcome is either specific behavior (`clamp`), `0`, or invalid to preserve for future use.

Yes, this is something we need to keep in mind when defining math expressions, but we should have a rule about which type of none "wins" in these cases. For `clamp()` specifically, since `none` is just syntactic sugar, whereas `none` for components has a behavior that cannot be emulated in any other way, I would err on the side of favoring the component meaning of `none`.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151#issuecomment-2053785148 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 13 April 2024 22:50:11 UTC