- From: Chris Lilley via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 14:42:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just [discussed](https://www.w3.org/2025/08/19-css-color-minutes.html#785c) `[css-color-5] Should color-mix() default to oklab interpolation?` and agreed to the following: * `RESOLUTION: Make the default interpolation space of `color-mix()` to OKLab` <details><summary>The full IRC log of that discussion</summary> github: w3c/csswg-drafts#10484 <br> lea: In past, we resolved that gradients should interpolate in OKLab (but then reverted it) <br> lea: gradients don't require interpolation space by default <br> lea: arugment about what to do by default <br> lea: but a lot of web-compat baggage for gradients <br> lea: for color-mix() we decided to not have a default, and everyone needs to type interpolation space <br> lea: but vast majority of authors have no idea <br> lea: many say in srgbl because their colors are srgb <br> lea: or use something just because it's what they know <br> lea: srgb produces the worst result! <br> lea: there are arguments for a variety of default space <br> lea: but in any case, we should pick one <br> lea: because we're better placed than most authors to pick a space <br> lea: most authors don't have the background <br> lea: and it also adds a lot of noise, especially when nested <br> lea: noise:benefit ratio is way too high <br> lea: MDN page didn't even explain why you need this argument until we fixed it <br> lea: so... thats the situation <br> lea: so let's pick a default. I recommend OKLab because perceptually uniform, so percentages make sense <br> TabAtkins: I agree personally <br> TabAtkins: I think using rectangular space is the right choice <br> TabAtkins: so sounds reasonable to me <br> TabAtkins: proposed resolution, make color space optional in color mix <br> TabAtkins: and default to OKLab <br> PROPOSED: Make the color interpolation space of color-mix() to OKLab <br> ChrisL: There's compat issues wrt transitions and animations <br> lea: this is just a syntax question <br> ChrisL: There's compat issues wrt transitions and animations <br> <lea> 🎉 <br> RESOLUTION: Make the default interpolation space of color-mix() to OKLab <br> <ChrisL> \0/ <br> ChrisL: Should transitions and animations also default to OKLab? That would be a change. <br> TabAtkins: We don't currently have a property to control the transition/animation color space <br> TabAtkins: I know we've attempted to have color-interpolation-method property in SVG, but never went anywhere <br> TabAtkins: can't remember why <br> lea: Might want different spaces depending on the operation, e.g. compositing <br> TabAtkins: right, ccameron wanted linear for compositing <br> TabAtkins: could we put into transition-behavior? <br> lea: This is much bigger scope, but, we do keep running into cases where you want to set parameters about how other properties work <br> lea: control multiple things, either differently per property, or for all images, or <br> lea: doesn't make sense to add a property for each property to control, and also doesn't make sense to control only all at once <br> lea: wonder if set metadata about how properties or values behave <br> lea: don't have a concrete proposal, just thought of this idea <br> TabAtkins: Given we don't have syntax at hand... <br> TabAtkins: Being able to set certain defaults for particular contexts, e.g. URL parameter stuff for all URLs at once, potentially interesting <br> TabAtkins: so there's scope for defaults for different types of things. <br> TabAtkins: but that would be a different issue! <br> TabAtkins: anything else? <br> <Zakim> ChrisL, you wanted to ask about transitions and animations (which do have a legacy) <br> fantasai: we discussed color-interpolation, said no because different use-cases want different things <br> fantasai: but color-interp doesn't need to have a single value <br> fantasai: could be auto by default, could be shorthand for color-interpolation-gradient/etc <br> fantasai: that would give you the ability to have defaults and tweak them across the page, easy to reset <br> fantasai: change animation/gradients/transitions but not change compositing <br> fantasai: but yes, i think it's super verbose to have to say the color space in every function, but we do it a lot <br> fantasai: i'm realistically not gonna fuss with gradients every time <br> ChrisL: though designers do <br> ChrisL: we know that not because they set the color space, but because they add 500 stops until it looks right <br> fantasai: so i think we shoudl pursue a set of color-interpolation-* properties <br> florian: suspect i agree. one thing that concerns me is - do we know how many longhands are part of this? can't grow the set forever <br> florian: do we have a good handle on how many things are reset by this? <br> fantasai: say you set c-i:transitions foo, gradient bar, else baz ...` <br> fantasai: but say we forgot about compositing <br> fantasai: your shorthand will take a single keyword, and will apply it to everything unless it should be different <br> fantasai: so compositing wouldn't get set by the longhand, just reset to initial <br> TabAtkins: because they all have a current behavior, so resetting to their initial value would be a no-op <br> TabAtkins: if we realize something later on that something new needs to be settable by the shorthand, and currently isn't <br> TabAtkins: e.g. if we add a new thing <br> TabAtkins: that seems less likely, because we can go through the things we need it for today <br> Florian: so addition isn't a problem, we just need to be careful when adding new things to say whether they get set or reset by the shorthand <br> </details> -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10484#issuecomment-3201053810 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 August 2025 14:42:53 UTC