CSS image() function

[jsnkuhn]

Description

The image() function allows an author to:

use [media fragments](https://www.w3.org/TR/media-frags/) to clip out a portion of an image

use a solid color as an image

fallback to a solid-color image, when the image at the specified url can’t be downloaded or decoded

automatically respect the image orientation specified in the image’s metadata"

Rationale

spec fixes many long standing issues with CSS images:

1. a simplified syntax for image spriting that doesn't require 3 different CSS properties: background-image: image('sprites.svg#xywh=40,0,20,20');. This also opens up the use of background-size and background-position for actual sizing and positioning of these images instead of dealing with the spriting.

2. ability to create a solid color image like this: background-image: image(red); instead of hacking a gradient like this: linear-gradient(red, red). Is good for devs because it's less repetition in the code and for browser vendors i'm guessing this would allow a path to a separate algorithm for just rendering a solid colored image.

3. Proper image fall-backs which url() can't do. When the image at the specified url can’t be downloaded or decoded, fallback to another image or color. This could lead to less background colors that are never seen being painted behind images.

4. automatically respect the image orientation specified in the image’s metadata.

FYI: the above are all from images-4 but the CSSWG is already looking at expanding image() in images-5 for things like background video and @image-manipulation

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=703217
chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=254753#c_ts1639769079
webkit bug: https://bugs.webkit.org/show_bug.cgi?id=72584

(looks like in webkit and firefox a considerable amount of work was done but then was just abandoned?)

Specification

https://drafts.csswg.org/css-images-4/#image-notation

Tests

https://wpt.fyi/results/css/css-images?label=experimental&label=master&aligned&view=subtest

• linked chrome bug is about image-set() not image() - https://bugs.chromium.org/p/chromium/issues/detail?id=630597

no tests yet for "Image Fragments" or "Bidi-sensitive Images"

only 5 tests right now all seems to be about "Solid-color Images" and "Image Fallbacks"

css-image-fallbacks-and-annotations.html
background: image("green.png", green);

css-image-fallbacks-and-annotations002.html
background-color: red;
background-image: image("support/1x1-green.png");

css-image-fallbacks-and-annotations003.html
background-image: image("1x1-green.svg", "support/1x1-green.png","support/1x1-green.gif");

css-image-fallbacks-and-annotations004.html
background-image: image("1x1-green.svg", "1x1-green.png", "support/1x1-green.gif");

css-image-fallbacks-and-annotations005.html
background-image: image(rgba(0,0,255,0.5)), url("support/1x1-green.png");

[foolip]

In the State of CSS 2022 question about browser incompatibilities, there was only a single mention of image(), so not enough to make the top list in #248.

That response just named "image()", with no additional detail.

[jsnkuhn]

I have a vague memory of a post from Tab some where saying that the working group wants image-set() implemented before image(). I don't remember the rational. Will share link if I run across that post again.

[foolip]

In the MDN short survey on CSS & HTML, "CSS images (border-image, image(), image-set())" was selected by ~19% of survey takers, putting it in the middle third of the 20 options. (There is some uncertainty as with any survey data.)

Since this option bundled together multiple proposals we can't know what resonated, but given the State of CSS results I'm fairly certain it was mostly image-set().

[gsnedders]

I have a vague memory of a post from Tab some where saying that the working group wants image-set() implemented before image(). I don't remember the rational. Will share link if I run across that post again.

@tabatkins do you know?

[nairnandu]

Thank you for proposing the CSS image() function for inclusion in Interop 2023.

We wanted to let you know that this proposal was not selected to be part of Interop this year. We had many strong proposals, and could not accept them all. It was unclear if this is a major problem for web developers or users. If you uncover evidence that it is, resubmitting a proposal in the future would be welcome.

For an overview of our process, see the proposal selection summary. Thank you again for contributing to Interop 2023!

Posted on behalf of the Interop team.