- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 21:21:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-conditional-5][css-color] Define `style()` color comparison in more precise terms``, and agreed to the following:
* ``RESOLVED: When comparing colors, `none` is only equal to `none` ``
* `RESOLVED: Whatever we resolve for comparing colors is also used to determine whether a transition starts`
* `RESOLVED: style() and transitions use the same color comparison method`
* `RESOLVED: If in same color space, compare components. 2. If in different color space and there's a "none", not equal. 3. If in different color space and no "none"s, convert to oklab and do epsilon comparison`
<details><summary>The full IRC log of that discussion</summary>
<emilio> lea: we have handwavy prose about how `style()` matching<br>
<emilio> ... for color each UA does its own thing<br>
<emilio> ... you can have black matching across different (old color formats) but doesn't match black for new color formats<br>
<emilio> ... I think we can do better<br>
<emilio> ... one challenge is we generally don't want to gratuitously convert to color spaces<br>
<emilio> ... and comparing using oklab with some epsilon<br>
<emilio> ... we want to limit them because they're not lossless<br>
<emilio> ... not also about precission but also missing values<br>
<emilio> ... so I think we might need to be a little smarter<br>
<emilio> ... maybe we pick one of the two color spaces based on some hierarchy<br>
<emilio> ... and if you end up getting a conversion to zero this wouldn't match<br>
<emilio> ... also should `none` match any number?<br>
<emilio> q+<br>
<TabAtkins> q+<br>
<emilio> ... do we say that matches or does it only match none?<br>
<ChrisL> q+ to aree none only matches none<br>
<emilio> ... if you want to resolve the none you can interpolate but they mean different things<br>
<emilio> ... and within that framework we're going to lose some nones but those wouldn't have matched anyways<br>
<kbabbitt> q+<br>
<emilio> ... anything to add ChrisL?<br>
<emilio> ChrisL: agree none should only match none<br>
<Rossen> ack emilio<br>
<TabAtkins> emilio: whatever we do here, we need it to be consistent with transitions<br>
<ChrisL> qq+<br>
<TabAtkins> emilio: I want to keep color comparisons basically the same<br>
<TabAtkins> emilio: it woudl be good to have the exact same test case and see if you get a transitionstart event<br>
<TabAtkins> emilio: so i think defining style() queries to match transitions makes sense, it's doing the same thing<br>
<TabAtkins> ChrisL: in the issue we're talking about adding a new section to Color called "comparing colors" which'll have the same sorts of algos as converting/etc and everyone will refer to that<br>
<TabAtkins> emilio: that sounds fine, yeah<br>
<TabAtkins> lea: i think the way nones behave in transitions now, if you transition from none to non-none, the component gets the same value along the entire transition<br>
<TabAtkins> emilio: that's different, that's interpoaltion behavior. we're worrying about whteher you *start* a transition or not<br>
<TabAtkins> lea: i agree<br>
<emilio> ack ChrisL<br>
<Zakim> ChrisL, you wanted to react to emilio<br>
<miriam> q+<br>
<emilio> ack TabAtkins<br>
<emilio> TabAtkins: wanted to say the same thing as emilio<br>
<emilio> ack ChrisL<br>
<Zakim> ChrisL, you wanted to aree none only matches none<br>
<Rossen> ack kbabbitt<br>
<emilio> kbabbitt: Agree that none should only equal none<br>
<emilio> ... also think we should minimize the number of color-space conversions we do<br>
<ChrisL> qq+<br>
<emilio> ack ChrisL<br>
<Zakim> ChrisL, you wanted to react to kbabbitt<br>
<emilio> ChrisL: a recent color-4 edit splits conversion between two steps<br>
<emilio> ... preparing and conversing<br>
<emilio> kbabbitt: my only observation is that the definition of "need to convert" might be different for interpolation vs equality<br>
<emilio> ChrisL: when you interpolate, before you start you look for missing analogous components<br>
<emilio> ... so there's an extra carrying forward step but otherwise identical<br>
<Rossen> ack miriam<br>
<emilio> miriam: I support this, in sass there's two type of color equality, same color in same format, and whether they resolve to the same when converted (equals and same)<br>
<emilio> ... seems we're looking for equals() and same()<br>
<emilio> ... for lengths whether they convert to pixels depends on whether you use `=` or `:`<br>
<emilio> ... the old syntax uses `--prop: <value>`, range uses ` = `<br>
<emilio> ... I believe with `<length>`s we treat them differently<br>
<emilio> q+<br>
<astearns> not sure if we should follow that precedent…<br>
<lea> q?<br>
<emilio> ... I wonder if we need to do the same thing there<br>
<emilio> TabAtkins: that's not right, they're the same<br>
<TabAtkins> emilio: the difference is whether the proeprty is registered or not<br>
<TabAtkins> emilio: if it's registered, the values are compared as length; if not they're compared as tokens<br>
<TabAtkins> emilio: same will apply to color properties<br>
<TabAtkins> miriam: there was an issuea bout unitless zeros... never mind<br>
<Rossen> ack emilio<br>
<lea> PROPOSED: When comparing colors, `none` is only equal to `none`<br>
<lea> PROPOSED: Whatever we resolve for comparing colors is also used to determine whether a transition starts<br>
<lea> PROPOSED: Minimize color space conversions when comparing colors in different color spaces, to preserve missing components to the extent possible. Do not convert both to a third color space, but convert only one of the two (exact algorithm TBD)<br>
<ChrisL> q+<br>
<lea> scribe+<br>
<lea> emilio: Even in the same color space, what about clamping?<br>
<emilio> ChrisL: hsl() gets stored as rgb anyways<br>
<lea> lea: Oh no, what happens with nones then?<br>
<emilio> (without none)<br>
<emilio> Rossen: first one should not be controversial<br>
<emilio> RESOLVED: When comparing colors, `none` is only equal to `none`<br>
<emilio> PROPOSED: Whatever we resolve for comparing colors is also used to determine whether a transition starts<br>
<emilio> RESOLVED: Whatever we resolve for comparing colors is also used to determine whether a transition starts<br>
<TabAtkins> Both style() queries and "does a transition start" use the same comparison logic<br>
<emilio> PROPOSED: style() and transitions use the same color comparison method<br>
<fantasai> +1<br>
<emilio> RESOLVED: style() and transitions use the same color comparison method<br>
<emilio> PROPOSED: Minimize color space conversions when comparing colors in different color spaces, to preserve missing components to the extent possible. Do not convert both to a third color space, but convert only one of the two (exact algorithm TBD)<br>
<emilio> ChrisL: is hsl() and rgb() the same color space?<br>
<fantasai> emilio: for legacy colors, some of the hsl() stuff gest stored as rgb<br>
<fantasai> emilio: doesn't trigger transitions<br>
<fantasai> emilio: Personally would be fine with converting to a third color space if needed, as long the color spaces are different<br>
<fantasai> emilio: We don't need to complicate things a lot<br>
<fantasai> lea: if non-none?<br>
<fantasai> lea: If none of the colors has a 'none'. Otherwise that would be lossy.<br>
<TabAtkins> (aka, if they're different color spaces and either has a 'none' they're *guaranteed* to be different colors<br>
<TabAtkins> )<br>
<lea> `oklch(0.9 0.2 none)` would not be equal to itself<br>
<fantasai> emilio: If you have 'none's in different coor spaces, can we just assume they're differnet colors<br>
<fantasai> ChrisL: Yes. Don't even need to do the conversion then.<br>
<fantasai> TabAtkins: When in the same color space, just compare components<br>
<fantasai> lea: Yes.<br>
<fantasai> emilio: If they're different color spaces and there's a none, they're not the same.<br>
<lea> `oklab(.9 none none)` and `oklch(.9 none none)`<br>
<Rossen> ack ChrisL<br>
<emilio> if a.color_space != b.color_space { if a.has_nones() || b.has_nones() { return false; } return a.to_oklab() == b.to_oklab() }<br>
<TabAtkins> 1. If in same oclor space, compare components. 2. If in different color sapce and there's a "none", not equal. 3. If in different color space and no "none"s, convert to oklab and do epsilon comparison<br>
<fantasai> lea: What you're proposing, ? would be lost<br>
<fantasai> ... although maybe not in this example because oklab<br>
<kbabbitt> s/? would be lost/`none`s would be lost/<br>
<TabAtkins> lea: we have rules about carrying nones between color spaces, component mappings. in your logic this would be lost here, these two would be treated as different<br>
<TabAtkins> emilio: for interpolation, yes, it's important those aren't lost and they're properly none-trnaistioned<br>
<TabAtkins> emilio: but for comparison, not as important<br>
<TabAtkins> emilio: i'm okay with more complicated if needed, but think it's just easier to compare in oklab when there's no none<br>
<TabAtkins> ack TabAtkins<br>
<Rossen> ack fantasai<br>
<emilio> fantasai: if we don't have a specific proposal maybe we take it back to the issue?<br>
<emilio> fantasai: TabAtkins has a couple points that he put on irc, #3 has some nuance<br>
<emilio> TabAtkins: same algorithm, effectively the same emilio wrote above<br>
<fantasai> astearns: Suggest we adopt that and tweak fro mthere.<br>
<TabAtkins> proposed comparison algo: . If in same oclor space, compare components. 2. If in different color sapce and there's a "none", not equal. 3. If in different color space and no "none"s, convert to oklab and do epsilon comparison<br>
<kbabbitt> sgtm<br>
<ChrisL> +1 for that<br>
<florian> q?<br>
<florian> q+<br>
<fantasai> lea: Can we continue to explore better alternatives?<br>
<emilio> lea: can we continue to explore better alternatives if we resolve on that?<br>
<fantasai> Rossen: keep improving!<br>
<emilio> TabAtkins: this is technically a behavior change to transitions right now, it's web observable already, presumably we'd be ok doing otherwise<br>
<emilio> florian: I support tab's proposal, but does color-space mean color-space or notation?<br>
<emilio> TabAtkins: don't care<br>
<emilio> ChrisL: colorspace<br>
<fantasai> lea: depends...<br>
<TabAtkins> Tallest citation wins<br>
<emilio> RESOLVED: If in same color space, compare components. 2. If in different color space and there's a "none", not equal. 3. If in different color space and no "none"s, convert to oklab and do epsilon comparison<br>
<fantasai> "different color space" TBD<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13157#issuecomment-4165667681 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 21:21:50 UTC