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/a5ede22f-26db-4aba-81f3-4dd0b0abbae3n%40chromium.org.
