Open eeeps opened 4 months ago
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.
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.
Some previous discussion in https://github.com/w3c/csswg-drafts/issues/6257
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.
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.
@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
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 https://github.com/w3c/csswg-drafts/issues/7519#issuecomment-1202721367.
But as I argued in https://github.com/w3c/csswg-drafts/issues/6257#issuecomment-850709682, 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.
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
First stab at a Web Platform Test https://github.com/eeeps/wpt/tree/object-fit-contain-size
I think the desired resolution here would be what @bfgeek proposed in https://github.com/w3c/csswg-drafts/issues/6257#issuecomment-849150205 - though it's not clear to me which spec (if any) needs to be clarified. Maybe we're just confirming this, and adding the WPT to prove it? :)
The CSS Working Group just discussed [css-images-4] Should `contain-intrinsic-size` affect `object-fit`?
, and agreed to the following:
RESOLVED: `contain` removes the natural aspect ratio / width / height only for the purposes of sizing and layout of the box (and object-fit is therefore not affected)
Ran into this today in Safari and submitted https://bugs.webkit.org/show_bug.cgi?id=276681
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 thecontain-intrinsic-size
dimensions, when paintingobject-fit
objects intocontain:size
d 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.