[css-images-4] Should `contain-intrinsic-size` affect `object-fit`?

[eeeps]

This question came up during sizes=auto spec/implementation work.

Here's a test page: https://codepen.io/eeeps/pen/mdgWNJo?editors=1101

WebKit thinks that it should, Chromium thinks that it should, and Firefox refuses to do any kind of object-fitting on size-contained elements.

Notably, @mirisuzanne thinks that it shouldn't, because contain-intrinsic-size doesn't actually change the natural dimensions of replaced elements (Image.naturalWidth/naturalHeight are unaffected), but simply tells the layout algorithm to proceed as if those were the natural dimensions.

I agree with her, and think UAs should use the actual natural dimensions that you get from Image.naturalWidth/naturalHeight, and not the contain-intrinsic-size dimensions, when painting object-fit objects into contain:sized elements. I think we need some more spec language somewhere here, although admittedly my understanding of some of the concepts here is provisional at best.

[mirisuzanne]

The reason for object-fit and related properties is to help align and size the image content inside a box that has different dimensions, or a different aspect ratio - because of some other specified styles. When we start applying those box layout dimensions to the image content, we lose the purpose of the feature.

[tabatkins]

Agreed, 'object-fit' 'itself clearly requires working on the actual image dimensions, or else it's worthless. The c-i-s dimensions are just to force layout stability. They only have an effect on the image's dimensions as a side-effect, since images default to stretching into their layout dimensions.

I'd have to poke around to figure out what, if anything, needs fixing in the specs; the language around intrinsic/natural dimensions is a bit wonky and there probably needs to be more "layers" of terminology here.

[Loirooriol]

Some previous discussion in #6257

[mirisuzanne]

We could close one of the issues, and add agenda+ to the other? It seems like there's consensus this is broken. And it seems like it should be clarified somewhere.

[vmpstr]

Is this a consequence of contain-intrinsic-size or size containment? Size containment says that

Replaced elements must be treated as having an natural width and height of 0 and no natural aspect ratio.

contain-intrinsic-size definition says:

These properties allow elements with size containment to specify an explicit intrinsic inner size, causing the box to size as if its in-flow content totals to a width and height matching the specified explicit intrinsic inner size (rather than sizing as if it were empty).

I couldn't find the reference for contain-intrinsic-size and natural size interactions.

In particular, in the codepen example (on Chromium), I can't get a different effect if I change contain-intrinsic-size to something like 800px 400px. It always remains a square.

[eeeps]

@vmpstr Try refreshing? This has been flaky for me before. Not sure if that's CodePen's fault, or Chromiums. Anyways here's proof that it does sometimes have an effect: https://o.img.rodeo/c2axgu9ms1l3ojujbjjn.png https://codepen.io/eeeps/pen/abxWVmN?editors=1101

[Loirooriol]

It always remains a square

Open devtools and set display: none, then unset it.

Is this a consequence of contain-intrinsic-size or size containment?

Size containment, which may be affected by contain-intrinsic-size.

I couldn't find the reference for contain-intrinsic-size and natural size interactions.

See the resolution in #7519 (comment).

But as I argued in #6257 (comment), this is just for sizing the <img>. Once we know its size, the spec says to lay out normally. So object-fit should work. And since the example uses width and height, contain-intrinsic-size should have no effect at all.

[vmpstr]

Got it working, thanks all!

And yes, it makes sense that contain-intrinsic-size affects the img element size not the interaction with object-fit

[eeeps]

First stab at a Web Platform Test https://github.com/eeeps/wpt/tree/object-fit-contain-size