[Webkit-unassigned] [Bug 233526] New: [CSS Color 4] Add support for "Missing"/"none" color components

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=233526

            Bug ID: 233526
           Summary: [CSS Color 4] Add support for "Missing"/"none" color
                    components
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: CSS
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sam at webkit.org

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211126/ea46cf0e/attachment-0001.htm>