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.
