Bug 1837250 [wpt PR 40426] - Parse rgb() like other color functions, …

…a=testonly

Automatic update from web-platform-tests
Parse rgb() like other color functions

Previously, rgb() and rgba() parsers were compressing all four color
channels and alpha to 8-bit integers. This is no longer necessary, as
blink::Color stores the parameters as floats.

As we move towards implementing relative color, the more unified the
color parsing is, the easier the eventual implementation will be.

After some discussion for Interop 2023, it was decided that non-finite
color parameters should round-trip and be resolved sanely:
http://github.com/w3c/csswg-drafts/issues/8629
This new requirement obviously puts us well out of 8-bit integer
territory.

Unfortunately, there are clearly still some code paths that are
independently compressing alpha to be an 8-bit integer and unless
we explicitly do this in the parser, many tests fail. A TODO has been
added to address this issue.

Here is the test change proposal: web-platform-tests/interop#369

Gradient tests with png expectations are pretty brittle, as evidenced
by the per-platform expectations. This change requires a rebaseline
because color channels are not squashed to [0,255] integer range at
the endpoints. So inputs like:
  conic-gradient(rgb(0%, 75%, 25%), rgb(0%, 25%, 75%));
No longer become equivalent to:
  conic-gradient(rgb(0, 191, 63), rgb(0, 63, 191));
25% of 255 is 63.75. 75% of 255 is 191.25.

Bug: 1452185
Change-Id: I1e89ad21d0e3007c1f51aa075728732c2856acc3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4598329
Reviewed-by: Florin Malita <fmalitachromium.org>
Reviewed-by: Steinar H Gunderson <sessechromium.org>
Commit-Queue: Aaron Krajeski <aaronhkchromium.org>
Cr-Commit-Position: refs/heads/main{#1166616}

--

wpt-commits: 207ddbd913b3f007271558329c116e8da16b7979
wpt-pr: 40426

UltraBlame original commit: bb939cc04443aa870a6a6b6088231ab172cc8c7a