Tracking bug: https://issues.chromium.org/issues/510426954
On Sunday, May 10, 2026 at 10:38:56 PM UTC+8 Chromestatus wrote: > *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* > > *Goals for experimentation* > None > > *Requires code in //chrome?* > False > > *Estimated milestones* > > No milestones specified > > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5121011285622784?gate=5122180825350144 > > 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/ca81d331-af5d-4124-b796-b3e81535569an%40chromium.org.
