Re: [csswg-drafts] [css-color-4] Consider not basing interpolation color space on input color types (#6914)

When we looked into usage of `color()` on the web as part of the Web Almanac, it was extremely low, so I doubt there are any significant web compat implications here.

I agree `color(srgb)` behaving differently than `rgb()` can be confusing. However, we cannot always require an interpolation space in gradients or transitions, and using sRGB interpolation by default for all colors just because of legacy is terrible.
I would be fine however using better interpolation for everything by default, as I doubt there are many websites that depend on the crappy gamma-encoded sRGB interpolation (and for the few cases that do, e.g. some kind of interpolation-related tool perhaps?, they can still specify an interpolation space explicitly, if that syntax is implemented at the same time.

Note that we still don't have syntax to specify interpolation for everything in CSS. E.g. there is nothing for transitions and animations yet.

I sympathize with your worry that we've already changed default interpolation space once, what if we want to change it again in the future. I've also worried about this, but having sensible defaults is one of the basic rules of good API design. The same reasoning could be extended to literally every default we have (what if we want to change it in the future?), but the language would have significantly worse ergonomics if we could not take advantage of defaults and initial values.

Btw, the reason we require an interpolation space in `color-mix()` was a compromise, because some UAs wanted to implement it with sRGB interpolation only, IIRC.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6914#issuecomment-1003645039 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 2 January 2022 01:06:59 UTC