Bug 233526 - [CSS Color 4] Add support for "Missing"/"none" color components
Summary: [CSS Color 4] Add support for "Missing"/"none" color components
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Sam Weinig
Keywords: InRadar
Depends on: 234741 234798
  Show dependency treegraph
Reported: 2021-11-26 11:02 PST by Sam Weinig
Modified: 2022-01-18 13:04 PST (History)
11 users (show)

See Also:

Patch (222.99 KB, patch)
2022-01-17 17:00 PST, Sam Weinig
no flags Details | Formatted Diff | Diff
Patch (223.28 KB, patch)
2022-01-17 17:05 PST, Sam Weinig
dino: review+
Details | Formatted Diff | Diff
Patch (223.28 KB, patch)
2022-01-18 11:36 PST, Sam Weinig
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Weinig 2021-11-26 11:02:39 PST
CSS Color 4 recently introduced a new concept and syntax for color components that allows an author (or the result of some computation like color-mix()) to specify a component of a color as being "missing" - https://drafts.csswg.org/css-color-4/#missing.

Missing components change the behavior of a color when interpolating with another color (the other colors component wins), but otherwise behave the same as 0. They are specified explicitly for any component using the keyword "none" and are similarly serialized that way.

The obvious (and somewhat standard) way of representing this value in our internal color types is via NaN, but that obviously only works for types that use floating point components. Legacy RGB 8-bit colors are another story. 

I can think of two options for legacy RGB 8-bit colors:

1. Force upgrade them to their floating point representation if a component is missing. (This has the down side of using more memory, though this will likely be rare, and will require us to re-evaluate the special serialization choices we make).
2. Use extra bits in Color to specify missing components. (This has the downside that anywhere we wanted to do interpolation, we would need to operate on Color objects and couldn't use the underlying value types directly).

I am leaning toward #1.

We will also have to re-evaluate the strategy we have for RGB projections HSL and HWB. Currently we convert those to 8-bit sRGB immediately when parsing, but this will likely mean making them real colorspaces and doing the conversion lazily when needed. This is probably a good idea anyway. They already have value types, we just need to add the color space naming.
Comment 1 Radar WebKit Bug Importer 2021-12-03 11:03:25 PST
Comment 2 Sam Weinig 2022-01-17 17:00:01 PST Comment hidden (obsolete)
Comment 3 EWS Watchlist 2022-01-17 17:02:18 PST Comment hidden (obsolete)
Comment 4 Sam Weinig 2022-01-17 17:05:02 PST
Created attachment 449356 [details]
Comment 5 Dean Jackson 2022-01-18 11:06:25 PST
Comment on attachment 449356 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=449356&action=review

> Source/WebCore/ChangeLog:17
> +        serialization, which has been updated to handle the new values, as welll as interpolation,

typo: welllllll
Comment 6 Sam Weinig 2022-01-18 11:36:42 PST
Created attachment 449406 [details]
Comment 7 EWS 2022-01-18 13:04:25 PST
Committed r288143 (246143@main): <https://commits.webkit.org/246143@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 449406 [details].