Bug 208465 - ExtendedColor doesn't work with animation
Summary: ExtendedColor doesn't work with animation
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Animations (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Sam Weinig
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-03-02 12:49 PST by Dean Jackson
Modified: 2021-12-27 11:33 PST (History)
4 users (show)

See Also:


Attachments
P3 color interpolation (572 bytes, text/html)
2021-12-23 18:14 PST, Simon Fraser (smfr)
no flags Details
Test case with computed output (1.01 KB, text/html)
2021-12-27 11:18 PST, Sam Weinig
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dean Jackson 2020-03-02 12:49:33 PST
We never implemented code to have ExtendedColors animate. I remember it being unclear what should happen if you are animating between Color Spaces, but we did address this for gradients.
Comment 1 Radar WebKit Bug Importer 2020-03-02 12:49:51 PST
<rdar://problem/59963499>
Comment 2 Simon Fraser (smfr) 2020-03-02 12:50:56 PST
Convert the endpoints into the deeper of the two colorspaces and then interpolate?
Comment 3 Simon Fraser (smfr) 2020-03-02 12:51:42 PST
Relevant: https://github.com/w3c/csswg-drafts/issues/4647
Comment 4 Simon Fraser (smfr) 2021-12-23 18:14:08 PST
Created attachment 447925 [details]
P3 color interpolation
Comment 5 Sam Weinig 2021-12-27 11:18:24 PST
Created attachment 448003 [details]
Test case with computed output
Comment 6 Sam Weinig 2021-12-27 11:33:59 PST
There are two things that need to done here:

1. Support animations of colors with a larger gamut than sRGB animating without eager gamut mapping them to sRGB. 

For consistency with precedent and gradients, I propose we use the unbounded sRGB (aka ExtendedSRGB in the engine) color space as the interpolation space. This has the effect that animating between two colors outside of the sRGB gamut would produce some computed color() functions with less than 0 or greater than 1 for component values (e.g. color(srgb 1.0930663624351615, -0.22674197356975417, -0.15013458093711937) for color(display-p3 1 0 0)).

As a general rule, I would like for us to avoid basing interpolation results on input colors, as I think that can lead to confusion to users, especially when coupled with things like CSS variables. For that reason, I don't think trying to give computed results in the color(display-p3 ...) form makes sense here.

The one exception to that rule is that I think we should special case the situation when the legacy color formats (srgb(), #fff, etc.) are used as both keyframes, and continue to return clamped 8-bit results. This would ensure that we don't break existing content that may be depending on that. 


2. Specifying which interpolation color space to use for an animation.

Gradients now support an additional parameter to specify the interpolation color space (https://drafts.csswg.org/css-images-4/#linear-gradients) using an optional <color-interpolation-method> production. 

I think we should extend CSS animations (and WebAnimations) to allow specifying per-keyframe pair interpolation color spaces. Exactly how that should work, where one would specify it, and whether it would be for all colors or per-color taking property (e.g. separate interpolation color space for background-color and color) will need to be worked out.

We will keep this bug about #1 and use https://bugs.webkit.org/show_bug.cgi?id=234702 for #2.