Webkit nightly now supports most of the standard syntax:
https://trac.webkit.org/changeset/255228/webkit
https://trac.webkit.org/changeset/254861/webkit
https://trac.webkit.org/changeset/254406/webkit

It's been unprefixed in webkit for a long time.

New PR for WPT with comprehensive web platform tests:
https://github.com/web-platform-tests/wpt/pull/21539

Chromium bug to unprefix:
https://bugs.chromium.org/p/chromium/issues/detail?id=630597&q=image-set&can=2

Now that we triage by severity, setting this bug's priority to P2 to represent near-term backlog status. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

will the ff implementation support type for image file type fallback mentioned in the spec?

background-image:
image-set( "foo.avif" type("image/avif"),
"foo.jpg" type("image/jpeg")
);

(In reply to jsnkuhn from comment #11)

will the ff implementation support type for image file type fallback mentioned in the spec?

The answer is yes, but we need to implement that. I posted instructions in bug 1695404.

Checked docs didn't include any out of date compat info and updated BCD and release notes.

When avif is disabled in about:config (which is the default in Firefox 88.0b7), the following image-set:

background: image-set(url("firefox.avif") 1x, url("firefox.jpg") 1x);

results in a blank div. Looking at the network inspector, it looks like the browser is downloading the avif file instead of the jpeg file, although it can't display it.

That's how it's supposed to work. In order to avoid requesting the image you need to use the type() function, which is being implemented in bug 1695404.

Sorry! I was mislead by type() not being implented yet.

Has there been any discussion of supporting -webkit-image-set() in Firefox. It appear from the MDN article ( https://developer.mozilla.org/en-US/docs/Web/CSS/image-set() ) that chrome at the very least has supported -webkit-image-set() since 2012. I understand that is no longer general practice to support prefixes but in this case that's 9 years of developers writing -webkit-image-set() code that could likely be supported by Firefox.

(In reply to jsnkuhn from comment #20)

Has there been any discussion of supporting -webkit-image-set() in Firefox. It appear from the MDN article ( https://developer.mozilla.org/en-US/docs/Web/CSS/image-set() ) that chrome at the very least has supported -webkit-image-set() since 2012. I understand that is no longer general practice to support prefixes but in this case that's 9 years of developers writing -webkit-image-set() code that could likely be supported by Firefox.

Might be worth considering adding an alias if there's any compat benefit, though I'd rather not, prefixes are lame ;)

Tom / Karl, have you seen any compat breakage related to -webkit-image-set? If you have examples of pages benefiting from this that'd be interesting too.

I don't recall ever running across any, but funny enough when Safari unprefixed it they ran into an issue with GMail, according to the comments on their bug (https://bugs.webkit.org/show_bug.cgi?id=160934)

As for Chrome, they still have an open issue to unprefix it (https://bugs.chromium.org/p/chromium/issues/detail?id=630597&q=image-set), but they don't seem to have made a decision on how soon to implement it (though they've recognized that we're unprefixing it in March).

Unfortunately the Chrome Platform Status page doesn't seem to be measuring image-set usage (or I'm tired and missing something).

All in all, I would say it's worth trying to ship it unprefixed first, and push the Chrome and Safari teams to drop the prefixes if possible.

Please note I just filed issue 1705877 which appears to use the wrong cursor size for imag-set() in a cursor property, which affects our PWA Construct 3 (www.construct.net).

would be nice if FF dev-tools could indicate which image from the set is getting used. Or I guess more consistent with the way dev-tools tends to work might be crossing out set options that the browser discards. Might also be nice to indicate to developers why a line was discarded. IE is a line not used because of a resolution issue or a mime type issue.

@jsnkuhn I agree with you, though could you please create a separate bug for your request? This one is just for the implementation of the feature itself. You may mark this bug being blocked by the new one, so there's a reference between the two.

Sebastian

Like Tom, I didn't see any issue related to a missing image-set() and probably it's hard to detect most of the time.
We can indeed find a certain number of them where there is a background property with a url, and a specific background-image with -webkit-image-set() only.
https://github.com/search?l=CSS&o=desc&q=%5C-webkit-image-set&s=indexed&type=Code

So maybe we never realized we were getting only a lower resolution?

Hmm. Given what Karl pointed out in comment 26, it looks like plenty of actual code used in the wild only specifies -webkit-image-set without the unprefixed version, so maybe it's worth implementing the prefix after all (also, Safari does not seem to have dropped the prefix).

Created also https://github.com/whatwg/compat/issues/144

This isn't working the same as it does on webkit, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1710837

(In reply to support from comment #29)

This isn't working the same as it does on webkit, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1710837

(closing the loop: this turned out to be bug 1705877 which is now fixed. It actually was already fixed on Nightly when comment 29 was posted, and just hadn't made it to release yet.)

Pretty sure this feature is done & shipped, and we can call this metabug "fixed". Any additional bugs that come along in this feature can still be tracked via this metabug as-appropriate, even with it being marked as closed, of course.

(Right now, the only still-open dependent-bug in Gecko here is bug 1696314, which is not supported in any browser and isn't particularly high-priority, per bug 1696314 comment 2.)

(Specifically: this is fixed/shipped as of bug 1698133, which is where we let this feature ride the trains to release in Firefox 88.)