Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 <fmalita@chromium.org> Reviewed-by: Steinar H Gunderson <sesse@chromium.org> Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Cr-Commit-Position: refs/heads/main@{#1166616}
- Loading branch information