- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 27 Jan 2026 19:14:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-4] Clarify that `none` is preserved in calculations``, and agreed to the following: * `RESOLVED: split mandatory conversion into (1) Converting powerless components to missing (2) Converting to another color space. This either calls 1 at the end, or if the two color spaces are the same, it only calls 1` <details><summary>The full IRC log of that discussion</summary> <dholbert> lea: implementations are prematurely converting 'none' to '0' which is lossy and doesn't reflect author intent<br> <dholbert> lea: the intent of that conversion is to avoid exposing color-space conversion math when you don't have anything better to do<br> <dholbert> lea: none is converted to the other component when you interpolate<br> <dholbert> lea: when you do calculations, you preserve 'none' in the same way that you preserve a variable; and then resolve 'none' when it gets output or interpolated<br> <dholbert> lea: chris added it to agenda because there was a lot of discussion after most recent resolution<br> <dholbert> lea: my understanding is to preserve 'none' until absolute last moment, when we display or interpolate<br> <dholbert> ChrisL: you'd proposed splitting it into two steps, one for converting none, one for doing color-space conversions<br> <dholbert> ChrisL: splitting it up makes it cleaner<br> <dholbert> lea: I don't remember this, but it sounds reasonable<br> <dholbert> ChrisL: you proposed it and I agree with it, and it'd make the spec more reasonable<br> <dholbert> ChrisL: There's something similar in the html spec<br> <dholbert> ChrisL: 0 hue in oklab is a reddish-purple, and we don't want these colors showing up<br> <dholbert> lea: "missing component" in that definition is something that contains none?<br> <dholbert> ChrisL: one is preserving 'none's that were specified<br> <dholbert> ChrisL: say you have a number for hue, e.g. '60', but the chroma is 0. then it's a missing or powerless component<br> <dholbert> lea: we use 'none' to represent such components, but also on its own<br> <dholbert> lea: [gives example]<br> <ChrisL> s/missing or//<br> <dholbert> lea: you don't want to replace the whole thing with 'none'; that's against author intent\<br> <romain> q+<br> <dholbert> lea: should convert the 'none' (not whole expression) to other component<br> <astearns> ack lea<br> <dholbert> romain: this makes sense, in the same color space<br> <lea> q?<br> <lea> qq+ to reply<br> <astearns> ack romain<br> <dholbert> romain: when there's none in a calc expression and you're interpolating between 2 different color-spaces, then you also have different value ranges<br> <dholbert> romain: so none+50 means one thing in rgb but another thing in ok[...] color-space<br> <lea> q-<br> <dholbert> ChrisL: but we have this concept of analogous components, and those would not be analogoous<br> <ChrisL> https://drafts.csswg.org/css-color-4/#analogous-components<br> <dholbert> lea: we're not talking about replacing values wholesale, we're talking about doing math with values.<br> <dholbert> ChrisL: oklch chroma and CIE ... factor of 100 different<br> <dholbert> lea: when you're converting between color-spaces, should be treated differently. Good point<br> <weinig> q+<br> <dholbert> romain: when same color-space and can be preserved, then it makes sense to do so. When converting to a different color-space, maybe it should become 0<br> <dholbert> lea: converting to 0 is unfortunate but I can't think of anything better to do<br> <astearns> ack weinig<br> <dholbert> weinig: this might be easier if we look at specific examples<br> <dholbert> weinig: I'm unclear which problem we're discussing<br> <lea> `linear-gradient(var(--accent-color), oklab(calc(none + .2) none none))`<br> <dholbert> lea: suppose you have a gradient like this^ ... the second color in that gradient<br> <romain> color-mix(<br> <romain> in srgb<br> <romain> rgb(calc(none + 50) 50% 0),<br> <romain> color(srgb 0.5 0.5 0),<br> <dholbert> you can interpolate with any color, and you have a darker color...<br> <romain> )<br> <romain> This was my example<br> <romain> Where `rgb` uses 0-255 but `color(srgb ...)` uses 0-1<br> <dholbert> lea: you can do this with relative color syntax too<br> <dholbert> weinig: I didn't think that 'none + .2' is a valid calc expression. doesn't parse at all, because none has no definition in calc<br> <dholbert> lea: you can end up with it, in relative color syntax<br> <dholbert> weinig: there's another github issue about how that should work<br> <dholbert> weinig: what's the problem in this github issue?<br> <dholbert> lea: we have a resolution to preserve it, whether we end up with 'none' explicitly or via relative colors<br> <dholbert> ChrisL: and that's not what's implemented. Everyone converts it to 0<br> <dholbert> lea: and that can become inaccessible<br> <dholbert> weinig: that's not the intent of the webkit impl; we try to preserve none as long as possible<br> <dholbert> weinig: maybe WPT has the wrong suggestions here for what is correct?<br> <dholbert> ChrisL: not sure, I'll put that flag on it<br> <dholbert> weinig: ignoring 'calc()' which is very complicated and orthogonal here... if you don't have calc, we should be preserving none as much as possible in color-mix<br> <dholbert> weinig: relative color syntax is a trickier one. We haven't defined how those letters should work with none<br> <dholbert> romain: this issue is about none in calc, in context of colors<br> <dholbert> lea: and how you end up with that combination doesn't matter. the question is how do you treat it<br> <dholbert> weinig: and we resolved that it's preserved in calc?<br> <dholbert> lea: yes<br> <dholbert> ChrisL: maybe partly because I didn't put it in the spec, because it was unclear<br> <dholbert> astearns: so we have the intent from previous resolution, just need clarifications<br> <dholbert> ChrisL: one of the clarifications was splitting the conversion, -- we now have this phase where you convert missing values to none, and *then* we talk about how to interpolate and convert colors<br> <dholbert> lea: the issue that romain posted, we don't know how to solve<br> <dholbert> ChrisL: i agree<br> <dholbert> weinig: lea, what does none + .2 mean in your example<br> <ChrisL> "the issue" being different ranges for numerical values<br> <dholbert> lea: you might have ended up with this type of color with relative color syntax. The intent is "i want to make the color darker"<br> <dholbert> lea: preserving the 'none' will match that intent<br> <lea> s/oklab(calc(none + .2) none none)/oklab(calc(none - .2) none none)/<br> <dholbert> weinig: the idea is to create the oklab with, instead of that calc, just a 'none' where the hue is, and then convert that oklab to whatever the hue is plus .2?<br> <dholbert> lea: should have been minus .2, sorry<br> <dholbert> weinig: after the fact replace the none there?<br> <dholbert> lea: yes<br> <dholbert> weinig: same if it was oklab? never mind, linear gradients default to oklab<br> <dholbert> astearns: is there a good definition for that initial split where we convert 0 to none?<br> <dholbert> ChrisL: yes. Lea said, on April 24, "instead of framing this as color-space conversion, we need 2 algorithms..."<br> <dholbert> ChrisL: [reads github comment]<br> <dholbert> ChrisL: that was a comment, not a resolution, but I'd like us to resolve that<br> <ChrisL> so let us resolve on what lea said, here https://github.com/w3c/csswg-drafts/issues/10211#issuecomment-2075829784<br> <dholbert> lea: currently the spec says when your'e converting color spaces that are compatible in some ways, and you have none values, that is preserved. e.g. oklch to lch, with 'none' in the hue, you preserve it<br> <dholbert> lea: but romain's saying if you're doing *math* with the component, then we can't preserve because the ranges are so different<br> <dholbert> lea: (e.g. chroma has different ranges in oklch vs lch)<br> <dholbert> lea: i think we should just say in that case, convert nones to 0<br> <dholbert> ChrisL: also, authors shouldn't be adding at all in that cases. they should be multiplying<br> <dholbert> lea: that's a good point... if we say it's converted to 0 when you're doing math, then mutliplying wouldn't work either<br> <romain> q+<br> <dholbert> lea: so maybe we should preserve it? and adding will end up with silly results, and that's the author's fault<br> <astearns> ack romain<br> <lea> qq+<br> <dholbert> romain: 3rd option: treat the whole expression as 'none'<br> <dholbert> not sure if that' sbetter but it's an option<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to romain<br> <dholbert> lea: this is the worst of all the options we have<br> <dholbert> lea: e.g. if you want to clamp lightness to a particular range, then you may end up converting the whole expression and losing the clamp<br> <dholbert> romain: same is true if you convert to 0? e.g. if you try to use +.1 to do a small change in lightness, then you get a giant change if we convert to 0<br> <lea> `oklch(from var(--color) clamp(0.5, l, 0.6) c h)`<br> <dholbert> lea: suppose you have this^ color<br> <dholbert> lea: if you end up with a color that has 'none' as the lightness<br> <dholbert> if you treat the whole expression as none, you end up with black there<br> <dholbert> you could end up with anything there. depends on what you interpolate with<br> <dholbert> if you treat the whole clamp as none, then you have no guarantees about the lightness<br> <dholbert> lea: the point is to guarantee the range, so you can compose it and ensure a certain level of contrast<br> <dholbert> romain: I don't disagree, but that's not unique to clamp... if you use a math expression, there are different best and worst cases<br> <dholbert> romain: for clamp it's bad to make the whole thing none, but for other expressions that might be the best case<br> <dholbert> romain: but I agree that for clamp, treating the whole thing as none is the worst case<br> <dholbert> weinig: in this example, where is the 'none' coming from?<br> <dholbert> lea: from --color<br> <dholbert> weinig: what might that be?<br> <dholbert> weinig: like a concrete color<br> <dholbert> weinig: would an example be `--oklch(none, ...)`<br> <dholbert> lea: yes<br> <dholbert> weinig: so if you're going from 'none' to this new thing, and you want to clamp the output to between 5 and 6....<br> <dholbert> lea: these are coming from different places. there might be design tokens from the web page itself, and you've got tooling that does math with them<br> <dholbert> lea: if you're trying to write CSS that's agnostic to what colors you get, then [missed]<br> <dholbert> weinig: how do I interpret what this color means as an engine?<br> <dholbert> ChrisL: yeah, how do you clamp none to between .5 and .6?<br> <dholbert> weinig: or is this going to be one color in a bigger expression that we then want to preserve that 'none'... do we need to preserve it until we do interpolation?<br> <dholbert> lea: that was the spirit of the resolution, yeah<br> <dholbert> weinig: so if we use your example as a background-color, it would be whatever clamp(0.5, 0, 0.6) would be?<br> <dholbert> lea: if you have to display it, you have to convert none to 0, so yeah you'd end up with .5 from the clamp expression<br> <dholbert> weinig: vs. if you interpolate, you'd replace it with the hue on the other side of the interpolation<br> <dholbert> lea: yes<br> <dholbert> weinig: got it. it does add a lot of complexity to color representation; we need to add more complexity to our internal representations<br> <lea> q?<br> <dholbert> weinig: not a dealbreaker; we already represent calc() deeply like this<br> <dholbert> lea: I think we have other features that cover this use-case, so if this adds tremendous complexity, it might not be worth it<br> <dholbert> lea: if implementation complexity is too high for something like this, we could step back and see what else can we do that might be more reasonable. But if it's manageable, I think this is the way to preserve author intent as much as we can<br> <ChrisL> "The clamp() function takes three calculations—a minimum value, a central value, and a maximum value—and represents its central calculation, clamped according to its min and max calculations, favoring the min calculation if it conflicts with the max. "<br> <ChrisL> So clamp(0.5, none, 0.6) = 0.5<br> <dholbert> weinig: I'd have to try to implement it to know for sure<br> <ChrisL> https://www.w3.org/TR/css-values-4/#comp-func<br> <ChrisL> q+<br> <dholbert> weinig: the current system where we use NaN to represent 'none' and keep that 'none' through interpolation is very nice. HAving to replace that with an AST would be unfortunate<br> <lea> q?<br> <dholbert> weinig: if there are other ways to do that and preserve that feature for how none can be translated to the system, that'd be great<br> <dholbert> but we can do it<br> <astearns> sck ChrisL<br> <astearns> ack ChrisL<br> <lea> q+<br> <astearns> ack lea<br> <dholbert> ChrisL: clamp() would indeed produce .5 in that scenario discussed above<br> <dholbert> lea: I'd be much more in favor of converting to 0 prematurely, as compared to making it infectious and making the whole expression none<br> <dholbert> lea: if preserving it has too high complexity, let's just convert it to 0; that's better than throwing away all the constraints<br> <dholbert> astearns: resolution?<br> <dholbert> lea: we could try speccing what we currently have, the resolution we already have<br> <dholbert> lea: if we get feedback from implementors that this adds to much complexity, then we can revisit and convert to 0<br> <dholbert> astearns: what do we need to add to preexisting resolution?<br> <dholbert> ChrisL: I want us to resolve on what lea said, splitting things into 2 stages<br> <romain> +1 to splitting to two stages<br> <dholbert> PROPOSED RESOLUTION: split into two stages as lea described in github<br> <ChrisL> split mandatory conversion into<br> <ChrisL> Converting powerless components to missing<br> <ChrisL> Converting to another color space. This either calls 1 at the end, or if the two color spaces are the same, it only calls 1.<br> <dholbert> romain: it'd be good to have some examples that we can run through, too<br> <dholbert> s/romain/weinig/<br> <dholbert> weinig: I think in wpt if you try to use none in calc it's a parse error<br> <dholbert> lea: that's definitely invalid<br> <dholbert> weinig: explicit none in there is invalid<br> <dholbert> lea: the intent of relative colors is that you can do conversions without having to worry about internal parse errors<br> <dholbert> weinig: that's the current grammar<br> <dholbert> RESOLVED: split mandatory conversion into (1) Converting powerless components to missing (2) Converting to another color space. This either calls 1 at the end, or if the two color spaces are the same, it only calls 1<br> <dholbert> lea: would it make sense to resolve that relative color syntax never results in a parse error, if you already have a valid color?<br> <dholbert> lea: I guess that's a design principle<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10211#issuecomment-3807032366 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 January 2026 19:14:48 UTC