Closed Bug 1107646 (image-set) Opened 7 years ago Closed 2 months ago

Implement image-set().

Categories

(Core :: CSS Parsing and Computation, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED

People

(Reporter: marcosc, Unassigned)

References

(Depends on 3 open bugs, Blocks 2 open bugs, )

Details

(Keywords: dev-doc-complete, Whiteboard: [tw-dom][layout:backlog])

Attachments

(3 files)

Implement image-set from CSS Image Values and Replaced Content Module Level 3 to enable a complete responsive images solution.
Alias: image-set
Up to now, only Firefox and IE (Edge) does not support image-set.

http://caniuse.com/#feat=css-image-set
Whiteboard: [tw-dom]
https://github.com/w3c/csswg-drafts/issues/1148 suggests to move this feature to css-images-4 due to a lack of implementations.

Sebastian
Can you please implement image-set() ? When devicePixelRatio is more than 1, and I use the custom cursor (PNG image), Firefox scales up the cursor according to devicePixelRatio (so it is blurry). W3C suggests to solve it with image-set() (which already works in Chrome for several years).
I want to do some cleanup of style images in bug 1440305 once I'm back from vacation. I'll do it with implementing this into account, so that implementing this is trivial-ish after that.
Depends on: 1440305
Summary: Implement image-set from CSS Image Values and Replaced Content Module Level 3 → Implement image-set().
Blocks: 1532331
Type: defect → enhancement
Blocks: css-images-4
No longer blocks: css-images-3
Priority: -- → P2
Whiteboard: [tw-dom] → [tw-dom][layout:backlog]

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

Flags: needinfo?(emilio)
Depends on: 1684770
Depends on: 1684909
Depends on: 1685078
Depends on: 1691275

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")
);

Depends on: 1695402
Depends on: 1695403
Depends on: 1695404

(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.

Depends on: 1696314
Depends on: 1698133

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.

Attached file image-set.html
Attached image firefox.jpg
Attached image firefox.avif

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.

Flags: needinfo?(emilio)

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.

Flags: needinfo?(twisniewski)
Flags: needinfo?(kdubost)

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.

Flags: needinfo?(twisniewski)

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).

Depends on: 1705877

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

Depends on: 1705947

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?

Flags: needinfo?(kdubost)

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).

Depends on: 1706448
Depends on: 1709415
Depends on: 1710422
See Also: → 1709415

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

Depends on: 1722400

(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.)

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED

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

You need to log in before you can comment on or make changes to this bug.