Skip to content

[css-animations][css-transitions][web-animations] Introduce a host-syntax for color interpolation #7741

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lilles opened this issue Sep 14, 2022 · 7 comments

Comments

@lilles
Copy link
Member

lilles commented Sep 14, 2022

css-color-4 introduces the concept of a host-syntax for color interpolation. For legacy colors, interpolation happens in sRGB for back compat reasons. When the relevant specs do not specify their own host-syntax for interpolation spaces, it falls back to OKLab for non-legacy colors.

We probably want to introduce a host-syntax for transitions and animations for explicitly specifying an interpolation space, and possibly also specify if the default interpolation space depends on which color space the endpoints or keyframe values are specified in.

See also issue #7567.

@mysteryDate

@svgeesus
Copy link
Contributor

Right, we need to add a <color-interpolation-method> to the grammar for those.

and possibly also specify if the default interpolation space depends on which color space the endpoints or keyframe values are specified in.

I think that is already covered:

If the host syntax does not define what color space interpolation should take place in, it defaults to OKLab.

However, user agents may handle interpolation between legacy sRGB color formats (hex colors, named colors, rgb(), hsl() or hwb() and the equivalent alpha-including forms) in gamma-encoded sRGB space. This provides Web compatibility; legacy sRGB content interpolates in the sRGB space by default.

This also means that authors can choose to opt-in to better interpolation, even between sRGB colors, by using the non-legacy color(srgb r g b) form for at least one of their colors.

@LeaVerou
Copy link
Member

LeaVerou commented Oct 20, 2022

How about transition-color-interpolation: [ auto | <color-interpolation-method> ]# with initial value auto which is whatever the UA does by default? Same for animations.

@lilles
Copy link
Member Author

lilles commented Oct 21, 2022

How about transition-color-interpolation: auto | <color-interpolation-method> with initial value auto which is whatever the UA does by default? Same for animations.

Should it take multiple values like other transition/animation properties? That is, should it be possible to transition color and background-color with two different methods on the same element?

@LeaVerou
Copy link
Member

How about transition-color-interpolation: auto | <color-interpolation-method> with initial value auto which is whatever the UA does by default? Same for animations.

Should it take multiple values like other transition/animation properties? That is, should it be possible to transition color and background-color with two different methods on the same element?

Correct. I updated my earlier comment.

@birtles
Copy link
Contributor

birtles commented Oct 31, 2022

If we're supporting multiple values, that sounds like this is a per-animation property (as opposed to per-element like it is in SVG).

In that case, I guess this should also be exposed on the underlying Animation JS object too.

Would this same property also affect how colors are added together? Or are colors not additive?

@svgeesus
Copy link
Contributor

svgeesus commented Nov 2, 2023

Would this same property also affect how colors are added together? Or are colors not additive?

We resolved that colors are not additive. Values 4 is up to date there

@svgeesus
Copy link
Contributor

svgeesus commented Nov 2, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants