[Spinning off from bug 1684958 comment 11. Original testcase on codepen: https://codepen.io/CodeRedDigital/pen/poxVmyq )

STR:

1. Load attached testcase.

EXPECTED RESULTS:
A gradient in each square.

ACTUAL RESULTS:
No gradient in the last two squares (the ones using ::before { content: linear-gradient(...);})

Chrome gives EXPECTED RESULTS.
Firefox gives ACTUAL RESULTS.

(ni=emilio since I suspect he'll be interested to take a look, as a followup from work in bug 1684958.)

So the image is there but gradients don't have an aspect ratio nor an intrinsic size, so the image ends up zero-sized... The spec isn't super clear on what to do here tbh. I'm not sure how chrome ends up with that size, I guess they give the gradient an aspect-ratio of 1?

Yeah, in the 3rd box in the attached testcase, where the ::before has no size properties, I would imagine it might be correct for that pseudo-element to be zero-sized. There's a case to be made for that, at least. (Arguably, for consistency, it should behave the same as an SVG image with no viewBox or size attributes on its SVG element -- I wonder how that behaves.)

In the testcase's 4th box where there's an explicit size, though, it seems pretty clear that it should behave as it does in the 1st and 2nd boxes (albeit with a slightly smaller box to fill, 35px rather than 40px).

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

Yeah, in the 3rd box in the attached testcase, where the ::before has no size properties, I would imagine it might be correct for that pseudo-element to be zero-sized. There's a case to be made for that, at least. (Arguably, for consistency, it should behave the same as an SVG image with no viewBox or size attributes on its SVG element -- I wonder how that behaves.)

I agree it should behave as an svg with no ratio or intrinsic size.

In the testcase's 4th box where there's an explicit size, though, it seems pretty clear that it should behave as it does in the 1st and 2nd boxes (albeit with a slightly smaller box to fill, 35px rather than 40px).

content: linear-gradient() really wraps stuff in another box, so there's an extra layer of indirection fwiw.

Hmm, so my expectations about how dimensionless-SVG would behave don't quite match reality.

Gecko (Firefox Nightly), Blink (Chrome dev), and WebKit (epiphany) all render the 3rd and 4th boxes in this "testcase 2" with the image sized to 300x150 (the fallback size, which is the same size that you get for an unsized img element:

data:text/html,<img src="https://bug1832901.bmoattachments.org/attachment.cgi?id=9333430">

That's probably not a great reference for how linear-gradient should behave. But it is at least an indication that painting something is better than painting nothing.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

I agree it should behave as an svg with no ratio or intrinsic size.

I'm not so sure now. :) See testcase 2.

In the testcase's 4th box where there's an explicit size, though, it seems pretty clear that it should behave as it does in the 1st and 2nd boxes (albeit with a slightly smaller box to fill, 35px rather than 40px).

content: linear-gradient() really wraps stuff in another box, so there's an extra layer of indirection fwiw.

That helps explain the behaviors here. I'm not sure I understand why that's behaving differently between boxes 2 and 4 in testcase 1 (both of them have content: linear-gradient() and an explicit size set on the same thing (in box 2 it's an element, in box 4 it's a pseudo-element). But I imagine there may be some historical reason that it works differently, and maybe there's another secret wrapper in box 4, maybe?

I attached a patch that adds some intrinsic size / ratio to these images just for demonstration purposes, but I'm not sure what the right behavior should be here. Might be worth raising an issue in the CSSWG repo.