[Color 4] Clean up the definition of color.same()

[nex3]

This was still written with the expectation that unknown color spaces
existed. It also makes missing channels equivalent to 0s even if they
survive the conversion to xyz.

[mirisuzanne]

The conversion makes sense. Not sure about none === 0 for this function.

[mirisuzanne]

What's the reasoning behind this? Just that they would result in the same display value?

[Goodwine]

First I thought it was probably OK since missing components are treated as zero according to the spec above. However, after skimming through the CSS spec, I now agree that for this function zero shouldn't be treated as equal to none 🤔, or maybe there has to be a note clarifying the scope of what same() is comparing to.

For example, IIUC from the CSS color spec example 33:

$color1: oklch(78.3% 0.108 326.5);
$color2: oklch(39.2% 0.4 none);
$color3: oklch(39.2% 0.4 0);

$with-none: color-mix(in oklch, $color1, $color2);
$with-zero: color-mix(in oklch, $color1, $color3);

This results in $with-none and $with-zero having different values, right?

And if so, I think it would be confusing in some situations for color.same($color2, $color3) to return true. But I guess it's fine if the function is meant to compare that two colors will display the same even if they don't behave the same in other situations like interpolating colors?

[nex3]

Here's my reasoning:

1. Missing channels are defined by spec as being treated as 0 everywhere other than interpolation. Since this is not an interpolation context, I think it fits the conceptual model to treat them as 0 here as well.

2. Missing channels are only well-defined within a given color space, and same() is trying to provide uniform behavior across color spaces. If we treat missing channels as distinct here, then there exists no Oklch color that's same() as rgb(none 150 255).

3. Relatedly, the previous definition already didn't consider missing channels in polar spaces (the place where they're by far the most meaningful and likely to arise naturally) as meaningful. Because it converts both colors into xyz, a missing hue is always treated identically to an undefined hue—which I think it good, because we want color.same(oklch(50% 0% 0deg), oklch(50% 0% 180deg)) to return true since they're both visually gray.

[mirisuzanne]

@nex3 Did you see the recent discussions around preserving none in calculations whenever possible? w3c/csswg-drafts#10211 (comment)

[nex3]

Interesting! I hadn't seen that. It does weaken point 1 somewhat, although I think in general the other points stand. I think making the distinction "== compares every little detail, same() compares whether the colors will look the same if you use them directly" makes sense.

[Goodwine]

Then I'm OK with it, but I think a comment should be added to make it clear that this same() is meant for colors that are displayed the same

[Goodwine]

First I thought it was probably OK since missing components are treated as zero according to the spec above. However, after skimming through the CSS spec, I now agree that for this function zero shouldn't be treated as equal to none 🤔, or maybe there has to be a note clarifying the scope of what same() is comparing to.

For example, IIUC from the CSS color spec example 33:

$color1: oklch(78.3% 0.108 326.5);
$color2: oklch(39.2% 0.4 none);
$color3: oklch(39.2% 0.4 0);

$with-none: color-mix(in oklch, $color1, $color2);
$with-zero: color-mix(in oklch, $color1, $color3);

This results in $with-none and $with-zero having different values, right?

And if so, I think it would be confusing in some situations for color.same($color2, $color3) to return true. But I guess it's fine if the function is meant to compare that two colors will display the same even if they don't behave the same in other situations like interpolating colors?

[mirisuzanne]

works for me