Summary: | color() function parsing incorrectly parses missing components | ||
---|---|---|---|
Product: | WebKit | Reporter: | Emilio Cobos Álvarez (:emilio) <emilio> |
Component: | CSS | Assignee: | Tim Nguyen (:ntim) <ntim> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | chris, heycam, karlcow, koivisto, m_dubet, ntim, sam, webkit-bug-importer |
Priority: | P2 | Keywords: | BrowserCompat, GoodFirstBug, InRadar |
Version: | Other | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | https://wpt.fyi/results/css/css-color/parsing/color-invalid-color-function.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2022-color%20or%20label%3Ainterop-2023-color |
Description
Emilio Cobos Álvarez (:emilio)
2023-01-25 08:15:00 PST
https://bugs.chromium.org/p/chromium/issues/detail?id=1410200 is the relevant chromium bug, for reference. I found this while reviewing patches to implement this in Firefox. After: document.body.style.color = color(srgb / 0.5) document.body.style.color WebKit 'color(srgb 0 0 0 / 0.5)' Gecko '' Blink 'color(srgb 0 0 0 / 0.5)' This used to be correct per spec, long ago when color() also did custom color spaces and it was reasonable to omit some components and have them auto-filled with zero. Now custom color spaces are in CSS Color 5, and clearly distinguished with a dashed-ident; while predefined color spaces are in CSS Color 4 and are wither an RGB space or an XYZ space. Both take 3 components, as the grammar makes clear. There was some leftover prose about variable number of components, not up to date with the grammar change, which I just corrected. Pull request: https://github.com/WebKit/WebKit/pull/11940 Committed 262098@main (77b199a5f044): <https://commits.webkit.org/262098@main> Reviewed commits have been landed. Closing PR #11940 and removing active labels. |