Fix color valid color mix test

[mysteryDate]

color-mix values should not get resolved at specified value time. See: #34158 and w3c/csswg-drafts#7302 (comment)

This PR changes keeps all the cases in the current test, but does not expect the color mix to resolve, only to resolve the input colors as they normally would at specified value time (i.e. #ff00ff -> rgb(255, 0, 255)).

There are definitely some cases that are missing here: calc values, keyword colors, current color, light dark pairs and hex colors. I'll add those next.

[mysteryDate]

@lilles

[svgeesus]

This looks good to me.

I noticed in reviewing that the test assumes lab and oklab, lch and oklch have similar ranges which they don't. But that could be fixed in a separate PR.

[lilles]

There are a lot of changes here, but generally lgtm. Firefox seems to have a pretty good impl in this area so if you could check if Firefox passes all, or if any failures are expected, before landing, that would make me more confident about these changes.

[mysteryDate]

I actually based these changes on Firefox. It still fails most of them because they do not yet handle "none" and is doing some computed-value stuff to the percentages that's not in the spec. Otherwise it matches.

[dbaron]

Looks like this was basically ready to merge, but it now has conflicts. Is it worth fixing and merging (and maybe addressing @svgeesus 's comment while doing so)?

[svgeesus]

Yes, it is worth re-basing to fix the conflicts.

[svgeesus]

@mysteryDate could you rebase this, to remove the conflicts?

[mysteryDate]

I think in the future we should try have smaller test files to avoid issues like this. There are only a couple changes on main that I'm conflicting with (mostly issues of rounding to 127 vs 128) but it's show as a massive conflict.

[mysteryDate]

They are resolved!

[mysteryDate]

We're having an issue where for a bunch of tests chrome and safari return 127 for the blue channel, though the upstream changes to this file expect 128.

For hwb(320deg 30% 40%) using the algorithm hwbToRgb as defined in this document, the result is:
[0.5999999999999999, 0.3, 0.5]

So the issue is that chrome and safari are evaluating 0.5 to an integer in the range [0,255] as 127, whereas the test expects 128. Which one is correct? Should the test accept either. This test is already doing a lot, we should probably test integer rounding somewhere else.

[svgeesus]

I think in the future we should try have smaller test files to avoid issues like this

That was how things were (small, focused tests for specific, small specification sections) until there was a massive rewrite which consolidated things into one-test-per-property style.

So the issue is that chrome and safari are evaluating 0.5 to an integer in the range [0,255] as 127, whereas the test expects 128. Which one is correct? Should the test accept either. This test is already doing a lot, we should probably test integer rounding somewhere else.

From CSS Color 4 5.1. The RGB functions: rgb() and rgba() which in turn references CSS Values 4 on rounding:

These values come from the fact that many graphics engines store the color channels internally as a single byte, which can hold integers between 0 and 255. Implementations should honor the precision of the channel as authored or calculated wherever possible. If this is not possible, the channel should be rounded towards +∞.

a = 0.5 * 255
127.5
b = Math.round(a)
128 

From round to the nearest integer:

Unless otherwise specified, in the CSS specifications rounding to the nearest integer requires rounding in the direction of +∞ when the fractional portion is exactly 0.5. (For example, 1.5 rounds to 2, while -1.5 rounds to -1.)

[svgeesus]

we should probably test integer rounding somewhere else.

It should probably be tested more generally in css/css-values, but here it is testing a specific reference from CSS Color 4.

[svgeesus]

I don't know how to get past the failing sink tasks which are blocking merging.

[dbaron]

Closing and reopening to re-trigger running of checks, since it looks like the underlying error was:

requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: https://hg.mozilla.org/mozilla-central/archive/tip.zip/testing/profiles/

[mysteryDate]

Okay, I've set this to round to 128 and not 127, I'll investigate why chrome is doing the wrong thing here.

[mysteryDate]

It should probably be tested more generally in css/css-values, but here it is testing a specific reference from CSS Color 4.

Isn't it just testing how "0.5 * 255" is rounded when converting hwb(320deg 30% 40%) to rgb?
https://jsfiddle.net/6yfqnLhs/

[mysteryDate]

Isn't it just testing how "0.5 * 255" is rounded when converting hwb(320deg 30% 40%) to rgb?
https://jsfiddle.net/6yfqnLhs/

I'm adding a simple parsing test to check this here:
https://chromium-review.googlesource.com/c/chromium/src/+/4507865

That was how things were (small, focused tests for specific, small specification sections) until there was a #36353 which consolidated things into one-test-per-property style.

It would be my instinct to call this test something like hwb-float-to-integer-rounding.html but to reflect the structure as is, I just added it to color-valid-hwb.html, at least with a comment explaining the intent of the test.