- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 04 Jun 2025 17:04:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-4] What if gradients with legacy colors *also* interpolated in Oklab by default?`, and agreed to the following: * `RESOLVED: Revert change to make all gradients interpolate in OKL by default` <details><summary>The full IRC log of that discussion</summary> <astearns> ack ChrisL<br> <fantasai> ChrisL: unfortunate situation that we took a resolution, but no browsers updated and WPTs test the current behavior<br> <fantasai> ChrisL: Two options<br> <jensimmons> What is the "reasonable proposal"?<br> <jensimmons> Can you summarize?<br> <fantasai> ChrisL: 1. we get implementers to say they're interested in doing this -- because so far we get people who are not happy with the proposed behavior<br> <fantasai> ChrisL: 2. we revert the resolution to match implementations and WPT<br> <fantasai> ChrisL: The thing we already have agreement on, and spec said for 18 months, is that all interpolation happens in OKLab unless you override<br> <fantasai> ChrisL: this means all interpolation changes, possibly for the better, but in any case it changes<br> <fantasai> ChrisL: I'd like us to either really do that, or really not do it<br> <fantasai> weinig: Implementing what's in the spec is easy. Most browser add additional checks for new vs old colors.<br> <fantasai> weinig: One challenge is that it will be a perf regression, at least for WebKit, to use OKL, since sRGB is much more optimized<br> <fantasai> weinig: so gradients will regress a little bit without special graphics backend. So that's one concern.<br> <fantasai> weinig: Another concern is changing websites<br> <smfr> q+<br> <ChrisL> q+ to say the main issue I see is unwillingness for backwards compat<br> <ydaniv> q+<br> <ChrisL> q-<br> <fantasai> weinig: That might be OK, but a bit hesitant to change all gradients that have ever existed on the Web<br> <astearns> ack smfr<br> <fantasai> smfr: Agree with Sams' perf concerns, and concern wrt legacy behavior<br> <lea> q?<br> <fantasai> smfr: Especially those that expect pixel-perfect behavior<br> <fantasai> smfr: e.g. iCloud docs<br> <lea> q+<br> <fantasai> smfr: so I think this does need to be opt in<br> <fantasai> weinig: No gradient will ever be pixel perfect, because by definition have dithering<br> <fantasai> weinig: but intention perfect<br> <fantasai> weinig: keynote document on mac, gradient renders different on mac and on web because we change interpolation<br> <fantasai> weinig: that would be unfortunate<br> <astearns> ack ydaniv<br> <jensimmons> q+<br> <ChrisL> q+ to say we have some wpt bugs because of dithering (which is allowed) but test reference assumes no dithering<br> <fantasai> ydaniv: although this is probably for the best, things like this could trigger CI failing when they update browser versions and suddenly screenshots and test tooling break randomly everywhere there's a gradient<br> <fantasai> ydaniv: I'm not sure how much that is a problem<br> <fantasai> ydaniv: sometimes happens because things change, but something to note<br> <fantasai> weinig: because gradients are this weird thing, they already break screenshot-based CI because they often have random or hardward-specific dithering<br> <fantasai> weinig: so all the places where could change, this is one with wiggle room<br> <fantasai> weinig: so if ppl have error bars, this might expand past<br> <astearns> ack lea<br> <TabAtkins> Tho, again, screenshot tools that allow specifying color-shift bounds can work fine with dithering, but won't work with changing the interpolation space.<br> <fantasai> lea: Wrt pixel-perfect, I've never seen pixel-perfect gradients used<br> <fantasai> lea: designiners who want that insert color stops to ensure the interpolation curve<br> <astearns> ack jensimmons<br> <lea> s/Wrt pixel-perfect, I've never seen pixel-perfect gradients used/I've never seen gradients that expect pixel perfect rendering really use sRGB. Even before in oklab was an option, they'd insert intermediate color stops to control interpolation, so the difference would be minimal./<br> <fantasai> jensimmons: I was surprised to hear that we decided to change default color space for gradients<br> <fantasai> jensimmons: surely there are designers and developers who don't care that much<br> <florian> q?<br> <TabAtkins> WPT, for example, lets you specify that pixels can be within an RGB unit or two of the reference.<br> <fantasai> jensimmons: also user gets new device, renders differently, or uses new browser<br> <fantasai> jensimmons: but certainly many designers obsess over the details and spent hours choosing the gradient ...<br> <fantasai> jensimmons: seems like CSSWG typically doesn't change out from how web works<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to say we have some wpt bugs because of dithering (which is allowed) but test reference assumes no dithering<br> <fantasai> jensimmons: so was surprised about resolution. Don't know if it's a good idea or not.<br> <fantasai> astearns: we resolved on this because it seemed like an improvement that could be ok with web-compat<br> <fantasai> astearns: but new behavior is fully accessible as an opt-in, right?<br> <fantasai> astearns: so we should probably resolve to revert this decision<br> <smfr> I tested Keynote on the web. It happens to use SVG, so it has an SVG gradient, but with just 3 stops. If it had used CSS this would have affected behavior<br> <florian> q+<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: I don't quite remember but is there a way for author to opt in whole page at once?<br> <kbabbitt> ChrisL: has to be each individual gradient<br> <kbabbitt> ChrisL: people keep suggesting it but folks say that wouldn't work because..<br> <kbabbitt> fantasai: that means we don't have a proper opt-in<br> <kbabbitt> ... requiring authors to do it for every gradient seems obnoxious<br> <lea> q+ what ChrisL is not a showstopper, just an additional complication in the design<br> <kbabbitt> ... the improvement that's available is unlikely to be worth that level of effort<br> <lea> q+<br> <florian> q- later<br> <kbabbitt> ChrisL: the gradients they can opt in are ... the ones that work how they want, they don't have to do anything with<br> <dbaron> q+ to comment on global opt in versus global behavior change<br> <kbabbitt> fantasai: if we think this is an improvement for all gradients, we should make it easy for authors to opt in<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <ChrisL> I hope we can make this first issue next week, as we are close to resolution<br> <astearns> ack lea<br> <fantasai> lea: We can still have a global setting. Having different interpolation spaces for different use cases is possible, just not a single property with a single value<br> <astearns> ack florian<br> <fantasai> florian: don't have statistics, but the point made by lea makes sense to me<br> <fantasai> florian: ppl who obsess over their gradients would use intermediary color stops, and would therefore be minimally affected by this<br> <fantasai> florian: on the other hand, argument from smfr about having things on and off the web look the same in both cases ...<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to comment on global opt in versus global behavior change<br> <smfr> I just disproved that apps add lots of color stops to control the rendering<br> <fantasai> dbaron: wrt global opt-in, if we thought global behavior change was good, then having global opt-in would make sense<br> <fantasai> ChrisL: global being problem was about all types of interpolation<br> <lea> e.g. color-interpolation-gradient<br> <florian> +1 to dbaron<br> <fantasai> lea, dbaron: we could have a global opt in that only affects gradients<br> <fantasai> astearns: should we resolve to revert?<br> <fantasai> ChrisL: I'd like to discuss an additional point next week<br> <fantasai> astearns: ok, let's do that and then continue with this discussion<br> <fantasai> astearns: proposed that we revert the change that says that gradients interpolate in OKL by default. Any objections?<br> <fantasai> RESOLVED: Revert change to make all gradients interpolate in OKL by default<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7948#issuecomment-2940774706 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 June 2025 17:04:16 UTC