That's my fault. The fact that Firefox shipped light-dark(none) to begin with was a bug / implementation accident due to how we represent images internally.
After the discussion in the CSSWG I promptly implemented image(<color>) and the relevant behavior (compute `none` to color(transparent)), see the relevant intent <https://groups.google.com/a/mozilla.org/g/dev-platform/c/MsmsVPkVbKQ> thread in dev-platform, but didn't make it to 151. It should ship in Firefox 152. Thanks, -- Emilio On Tue, May 26, 2026, at 8:24 PM, 'Dan Clark' via blink-dev wrote: > The WPTs for image() and light-dark(none,...) still fail on Firefox Stable > 151, while the WPTs for light-dark() that don't depend on image() or 'none' > pass in Firefox Stable 151. So it seems they didn't consider image() to be a > blocking prerequisite for shipping light-dark(), and it's not clear to me > when they intend to ship it. So it looks to me like we should still file a > Mozilla request for position on this, unless you're able to confirm that it's > shipping in an upcoming Firefox Stable release not gated by an experimental > flag. > > -- Dan > On Tuesday, May 26, 2026 at 4:49:26 AM UTC-7 一丝 wrote: >> NOTE: This is a prerequisite for the Ship “CSS light-dark() with image >> values.” >> See: https://groups.google.com/a/chromium.org/g/blink-dev/c/OfZ5uS1XAnc >> >> 在2026年5月26日星期二 UTC+8 14:25:11<Chromestatus> 写道： >>> *Contact emails* >>> [email protected] >>> >>> *Specification* >>> https://drafts.csswg.org/css-images-4/#image-notation >>> >>> *Summary* >>> The image() function allows an author to easily generate a solid-color >>> image from any color. Its syntax is: image() = image( <color> ) >>> >>> *Blink component* >>> Blink>CSS >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> >>> >>> *Web Feature ID* >>> image-function <https://webstatus.dev/features/image-function> >>> >>> *Motivation* >>> CSS has long needed a primitive way to express a transparent image: an >>> <image> value with no intrinsic dimensions that paints nothing. Authors >>> today reach for awkward workarounds like linear-gradient(transparent) to >>> fabricate one, because the none keyword cannot be used as a generic image. >>> Many properties that accept <image> also accept none with property-specific >>> meaning (for example, in list-style-image, none suppresses the marker >>> rather than drawing a transparent image), and none is not a valid <image> >>> for registered custom properties using syntax: "<image>". The CSS Working >>> Group has confirmed that promoting none to a general image type is >>> unworkable. This gap became concrete in the design of light-dark() from CSS >>> Color 5. The specification allowed light-dark(none, none) and described it >>> as equivalent to linear-gradient(transparent), but that definition does not >>> round-trip: when the chosen value is none, the result needs a real <image> >>> representation that is valid everywhere <image> is accepted, including >>> inside registered custom properties and in contexts like list-style-image >>> where the bare keyword none carries a different meaning. Without a >>> dedicated image primitive, implementations were forced either to refuse >>> none inside light-dark() (as Firefox originally did) or to special-case it >>> in ways that leak through computed values. The CSS image() function, >>> already specified in CSS Images Level 4, provides exactly the needed >>> primitive. In particular, image(<color>) produces an image with no natural >>> dimensions filled with a solid color, and image(transparent) is a fully >>> transparent image that is unambiguously an <image> value in every context. >>> The CSS WG resolved that light-dark(..., none) computes to >>> image(transparent) when none is the chosen branch, which both fixes the >>> round-trip problem and gives authors a clear, intuitive way to spell "a >>> transparent image" without abusing gradient syntax. Shipping image() >>> (initially scoped to its <color> form, since the broader features of >>> image() can be deferred) therefore unblocks light-dark(), supports >>> registered <image> custom properties that need a transparent initial value, >>> replaces the common linear-gradient(transparent) idiom with a direct and >>> self-documenting expression, and lays the groundwork for the remaining >>> capabilities of image() in CSS Images 4. >>> >>> *Initial public proposal* >>> *No information provided* >>> >>> *TAG review* >>> *No information provided* >>> >>> *TAG review status* >>> Not applicable >>> >>> *Goals for experimentation* >>> None >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> *No information provided* >>> >>> *Gecko*: Shipped/Shipping >>> (https://bugzilla.mozilla.org/show_bug.cgi?id=2023569) >>> light-dark(none,none) depends on image(none) >>> >>> *WebKit*: No signal >>> (https://github.com/WebKit/standards-positions/issues/658) Note: >>> light-dark(none,none) depends on image(none) >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> *WebView application risks* >>> Does this intent deprecate or change behavior of existing APIs, such that >>> it has potentially high risk for Android WebView-based applications? >>> >>> *No information provided* >>> >>> >>> *Debuggability* >>> *No information provided* >>> >>> *Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)?* >>> Yes >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> Yes >>> https://wpt.fyi/results/css/css-images/parsing/image-function-valid.html >>> https://wpt.fyi/results/css/css-images/parsing/image-function-computed.html >>> https://wpt.fyi/results/css/css-images/parsing/image-function-invalid.html >>> >>> *Flag name on about://flags* >>> *No information provided* >>> >>> *Finch feature name* >>> CSSImageFunction >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> https://issues.chromium.org/issues/510426954 >>> >>> *Estimated milestones* >>> Shipping on desktop 150 >>> Shipping on Android 150 >>> Shipping on WebView 150 >>> >>> >>> *Anticipated spec changes* >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> >>> *No information provided* >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5121011285622784?gate=4711380222607360 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a009871.050a0220.3695eb.00b3.GAE%40google.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. > > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12b96bd7-7739-4d40-9cbe-87c4fb627213n%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12b96bd7-7739-4d40-9cbe-87c4fb627213n%40chromium.org?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5b5e8008-240a-4b9d-9970-809b7a7aaecf%40app.fastmail.com.
