- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 22:48:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-5] Support `light-dark(<color>, <image>)` by producing a dimensionless image for `<color>` ``, and agreed to the following: * `RESOLVED: No change to this spec. Move image() other than image(<color>) to next level of css-images. Add image(<color>) to CSS Snapshot 2026 "safe to release" list` <details><summary>The full IRC log of that discussion</summary> <emilio> lea: recently we resolved on a `light-dark(<image>, <image>)`<br> <TabAtkins> q+<br> <emilio> ... if you specify colors you get a color, if images you get an image<br> <emilio> ... having a parse time color-or-image is not possible<br> <emilio> ... but why not encode the workaround of wrapping the thing on a linear-gradient<br> <emilio> ... making the type of an argument depending on another seems better?<br> <emilio> s/better/weird<br> <emilio> ... but it's a bit of a philosophical argument<br> <emilio> ... `image()` would be an option but doesn't exist now<br> <astearns> ack TabAtkins<br> <emilio> ... so I propose to do the auto wrapping to match author expectations<br> <emilio> ... I wonder if it'd be better to do `light-dark-image()` since then it'd be very clear<br> <emilio> q+<br> <emilio> TabAtkins: I wrote some objections in the issue, I'd rather not do colors-as-image in random spots<br> <emilio> ... because we can't do that arbitrarily<br> <emilio> ... I'd much rather implement `image()`<br> <emilio> ... when possible I'd prefer not having an argument influence the other<br> <emilio> ... doesn't feel great from a language design perspective<br> <emilio> ... prefer no change<br> <emilio> ... leaning on image() or linear-gradient() to get solid images<br> <emilio> +1<br> <astearns> ack fantasai<br> <emilio> fantasai: I'm with tab on this one<br> <emilio> ... if we want to just `image(<color>)` be L1 of that feature that seems fine as well<br> <emilio> emilio: I was going to make the same proposal<br> <lea> +1 to `image(<color>)` as the MVP of `image()` (I'm surprised that's not the case already)<br> <kizu> +1 to start from a simple `image(<color>)`<br> <astearns> ack emilio<br> <fantasai> emilio: Instead of linear-gradient() let's just simplify image() to <color><br> <emilio> emilio: making `image(<color>)` the MVP and extending later seems fine if people find it weird<br> <lea> PROPOSED: No change, `image(<color>)` to be added to css-images-5 (?)<br> <fantasai> It's in L4 already<br> <ChrisL> https://drafts.csswg.org/css-images-4/#image-notation<br> <lea> PROPOSED: No change, `image()` to be moved to css-images-6, `image()` in css-images-5 to be pared down to `image(<color>)`<br> <fantasai> PROPOSED: No change to spec. Add image(<color>) to the CSS Snapshot 2026<br> <lea> PROPOSED: No change, `image()` to be moved to css-images-5, `image()` in css-images-4 to be pared down to `image(<color>)`<br> <fantasai> PROPOSED: No change to spec. Add image(<color>) to the CSS Snapshot 2026's "safe to release" exception list.<br> <fantasai> PROPOSED: No change to this spec. Move image() other than image(<color>) to next level of css-images. Add image(<color>) to CSS Snapshot 2026 "safe to release" list<br> <fantasai> RESOLVED: No change to this spec. Move image() other than image(<color>) to next level of css-images. Add image(<color>) to CSS Snapshot 2026 "safe to release" list<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13724#issuecomment-4166131432 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 22:48:38 UTC