[css-sizing-4][css-contain] Clarify on specifying aspect-ratio and contain:size on replaced elements

[aethanyc]

Per 3.1. Size Containment,

Replaced elements must be treated as having an intrinsic width and height of 0.

I read above as the replaced element should be treated as having no intrinsic aspect ratio as well. So if a replaced element has both aspect-ratio and contain:size, what size should it be? An example:

<img src="https://placehold.it/300x100" style="width: 100px; aspect-ratio: 1/1; contain:size">

Here a link to the above example. https://jsfiddle.net/tL3xh6qo/2/ (Currently, both Firefox and Google Chrome render the example as 0x0, 100x0.)

I would think the image size should be 100x100, not 0x0 100x0, because contain:size affects only intrinsic aspect ratio, and aspect-ratio property provides a preferred aspect-ratio, which should be used to determine the size.

[edit: Changed the size of the example currently rendered on browsers from 0x0 to 100x0.]

CC @cbiesinger, @fantasai, @BorisChiou, @emilio

[cbiesinger]

Yes I agree that it should be 100x100. This seems to be a bug in Blink.

[emilio]

Hmm, I'm not sure... at least for the mapped ratio case (so <ratio> && auto). That's supposed to replace the intrinsic ratio...

[cbiesinger]

Hm...

@fantasai @bfgeek @tabatkins for input

Also @dvoytenko do you have any thoughts on this?

[dvoytenko]

I also think it should be 100x100. Just based on the aspect-ratio: 1/1. I don't know fully the nuances of how contain: size is applied. But I think perhaps, without width/height attributes and no contain-intrinsic-size specified, it could be just possible to define this case as "unknown intrinsic size" where the explicit aspect-ratio wins out, but we lose some of the derivatives from the intrinsic size, such as min-width computations?

[x-Jake-x]

I believe in the example it's actually rendering as 100x0, not 0 x 0 (at least in my version of the browser):

https://jsfiddle.net/fh6b17vp/

It could be that the UA is:

1. generating the containing box (principal box) from the IMG element (https://www.w3.org/TR/css-display-3/#atomic-inline), (300 x 100)
2. then giving it a width and height of 0 due to not having any contents (https://drafts.csswg.org/css-contain/#containment-size),
   (0x0)
3. then applying the aspect ratio as an "effective aspect ratio" to the box and replaced image (this terminology is not defined in the Editor's Draft), doing nothing ((https://drafts.csswg.org/css-sizing-4/#ratios),)
   (0x0)
4. then applying the specified width to the size-contained box
   (100x0)
5. then filling that box with an ill-defined image (100x?)

But who knows what's really going on behind-the-scenes there for each implementation? I'm not sure that the order of operations is well-defined for how the Containment Module applies itself yet...

Also, I noticed on my version of Chromium that this still leaves a 1px tall interior to the box whereas there should have probably been nothing, whereas Firefox collapses the borders completely. Chromium also seems to apply this padding around the image, not just the resized box.

However, https://drafts.csswg.org/css-images-3/#concrete-size-resolution says "CSS does not define how objects render when the concrete object size is different from the object’s intrinsic dimensions." and the Containment Module explicitly states that the layout for "Replaced elements must be treated as having an intrinsic width and height of 0." as @aethanyc mentioned. If concrete object size for the image has already been calculated prior to the object's intrinsic dimensions being treated as zero, the rendering of the image could end up being undefined by CSS, which could explain why Chromium has a gap and Firefox does not.

https://drafts.csswg.org/css-contain/#containment-size also says "When calculating the size of the containing box, including when computing its intrinsic size, it must be treated as having no contents." and then it says "Then, its contents must then be laid out into the containing box's resolved size." What exactly is the "resolved size" here? I feel like this should be better defined, possibly including more information on how to handle replaced elements who end up getting replaced into their own box.

[aethanyc]

@x-Jake-x Thanks for pointing this out. Both Firefox and Chrome do render the example as 100x0. I'll edit my original post.

[tabatkins]

Yes, contain:size censors the intrinsic aspect ratio, but an explicit 'aspect-ratio' value will still give the element an aspect ratio. So the element in the OP's example should be 100x100.

There's a related question of how the width/height attributes on an img are interpreted; I think the most reasonable and consistent answer is that their ratio is mapped to 'aspect-ratio' as a presentational hint (same as width/height are mapped to 'width'/'height', and so it's respected even when contain:size is specified.

This isn't correct per-spec right now, but whatwg/html#5907 has been filed to fix this.

[cbiesinger]

@tabatkins So is my interpretation correct that "auto 1/2" should also be used in case of contain:size?

[tabatkins]

@cbiesinger I'm a little confused, but I'm assuming you're asking, unrelated to any of the above discussion, about an element that has aspect-ratio: auto 1/2; contain: size; on it?

Yes, the 1/2 ratio should be used. contain:size should be censoring the intrinsic aspect ratio, so the auto doesn't do anything, and the explicit 1/2 takes over instead.

(I've opened #5585 now to cover the fact that aspect-ratio isn't actually mentioned in relation to contain:size...)