Bug 233526

Summary: [CSS Color 4] Add support for "Missing"/"none" color components
Product: WebKit Reporter: Sam Weinig <sam>
Component: CSSAssignee: Sam Weinig <sam>
Status: RESOLVED FIXED    
Severity: Normal CC: clopez, darin, dino, esprehn+autocc, ews-watchlist, glenn, gyuyoung.kim, macpherson, menard, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 234741, 234798    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch
dino: review+
Patch none

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
<rdar://problem/86026087>
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]
Patch
Comment 5 Dean Jackson 2022-01-18 11:06:25 PST
Comment on attachment 449356 [details]
Patch

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]
Patch
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].