https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html has some failures specifically around image-set being set as a value for the content property. These ones in particular:

e.style['content'] = "image-set(linear-gradient(black, white) 1x, url("example.png") 4x)" should set the property value
e.style['content'] = "image-set(url("example.png") 192dpi, linear-gradient(black, white) 1x)" should set the property value

...(and their webkit-prefixed equivalents)

As of now, these are the bottom-most failures for this test; the ones further up are regarding calc and are bug 1821782.

It looks like Firefox only supports url()-valued <image> expressions for the content property, but doesn't support e.g. linear-gradient() expressions there, nor image-set expressions (which is what the test uses).

Here's a testcase with just linear-gradient (not image-set) in the content property, for simpler cross-browser comparisons, since not all browsers support image-set.

We support linear-gradient as a value for background-image but not for content apparently.
Chrome does support it as a value for content (renders a lime rect).
Epiphany/WebKit sort-of supports it -- they render a transparent black-bordered div in this testcase, for some reason. I think that indicates that they're parsing it successfully but they're failing to paint it for some reason.

Looks like the css-content-3 spec does call for generalized <image> values to be accepted, so I think this WPT test (and Chrome's rendering of my attached testcase 1) is valid.

Spec link: https://drafts.csswg.org/css-content-3/#propdef-content

Specifically, it defines the property like so:

Name: content
Value: normal | none | [ <content-replacement> | <content-list> ] [/ [ <string> | <counter> ]+ ]?

and then explains <content-replacement> like so:

<content-replacement>
Equal to:
<image>

(And of course the <image> grammar includes gradients and now image-set as well, per https://drafts.csswg.org/css-images-4/#image-values )

We implemented content:url(foo.png) support in bug 215083, though I think (?) it was limited to just url(). I don't recall why we didn't support generalized <image> there -- maybe just for simplicity & to address a webcompat need in a targeted way? (emilio, do you recall why we didn't implement generalized <image> support for content, and is there anything blocking us from doing so now?)

Just found bug 1684958 and midair'ed the dupe. :) Thanks!

(In reply to Daniel Holbert [:dholbert] from comment #2)

We implemented content:url(foo.png) support in bug 215083

Correcting myself: that was specifically about implementing it for elements (as opposed to pseudo-elements). It looks like content: url(foo.png) worked on pseudo-elements for quite a while before that.