17 comments

[ 2.8 ms ] story [ 55.4 ms ] thread
I think I'd rather put the aspect-ratio on the element that wraps the img. And then use object-fit on the img. Two reasons:

- Allows for using the img tag sizes (and srcset)

- When using sizes (w/ srcset) I don't have to worry if the image the browser picks from the srcset isn't the correct size and/or aspect ratio.

I think you are agreeing with the article, but the details are different. I like how he distinguishes between specific use case, user generated content, or part of the site design.

> So, which method should we use?

> We've got one solution, aspect-ratio, which is CSS-based. And the other solution, presentational hinting, which uses width and height attributes. The question is very similar to "should this image be a <img> or a CSS background-image?" and the answer is the same: Is it content or design?

I also use the wrapper pattern for my recent projects, but the primary reason is for avoiding layout shifts (I didn't know a simpler solution exists until I read this article). The approach is quite different than what the article suggests: rather than setting a specific width and height on the img element, I simply set it to 100% for the wrapper and img elements (and the rest are the same as yours: I set aspect-ratio on the wrapper and object-fit on the img element).
i really dislike wrapper patterns of any kind, as they add needless markup. sure, it's ok if used sparingly to paper over the inadequacies of current html/css, but it's often used excessively nowadays, just like tables in days past. the element itself, not a superfluous wrapper, should provide the parameters necessary (implicitly or explicitly) to specify layout and prevent layout shift.

it sounds like the author takes an either-or approach to this, using either aspect-ratio (for design images) or height and width (for content images). having only skimmed, i haven't yet digested why hinting via attr(height) and attr(width) isn't the (future) preferred best-of-both-worlds, other than it not being supported yet ( https://caniuse.com/css3-attr ).

The lack of support is the only reason, but that's a pretty big reason. Hopefully, in future, web devs will be able to add the same feature to things like iframes via attr(width number) - the number casting will still be necessary.
yah, i can’t wait for attr() to be fully supported. it’s going to both simplify css and reduce js reliance.

i’m also really excited by :has() which i think will be the biggest improvement to css since grid. firefox has just started working on it, while safari and chrome already have an initial implementation in place.

Not a fan either. But when working with WordPress it takes extra work to ensure all the images in the srcset have the same aspect ratio.

So the only way to ensure cover is object-fit.

Note: this is also useful for background images in the sense totoo often the same large HD+ image is served to mobile devices.

Even if you set width and height attributes, you can still set the image to 100% width using CSS. That's how all the examples in the article work. You don't need a wrapper element.
The point in the article is you don't need that wrapper. Just add the width & height to the image, and give the image `height:auto`.
And what about object-fit?

Best I can tell, the article works if you are 100% certain that all the images in the srcset have the same aspect ratio.

With, for example WordPress, that is often not the case.

All images in the srcset are supposed to be the same aspect ratio. If WordPress is doing something different then it's a bad implementation.

From https://html.spec.whatwg.org/multipage/images.html#introduct...

> The srcset and sizes attributes can be used, using the w descriptor, to provide multiple images that only vary in their size (the smaller image is a scaled-down version of the bigger image).

If you want different representations of the content, those should be different <source>s.

From https://html.spec.whatwg.org/multipage/images.html#introduct...

> The picture element and the source element, together with the media attribute, can be used to provide multiple images that vary the image content (for instance the smaller image might be a cropped version of the bigger image).

More details on responsive images in general https://jakearchibald.com/2015/anatomy-of-responsive-images/.

I just threw together a test page, and it seems like WordPress does the right thing https://jakesdemosite975920295.wordpress.com/2022/07/12/test....

Maybe you're using a custom theme that introduces buggy behaviour?

I don't think so. I've seen this behavior for years across a number of themes and projects, as well as inspecting sites with dev tools.

WordPress can't know, or at least be 100% certain of the image's dimensions. Yes, you can add custom images but there's no guarantee those will yield after the auto-resizing.

I created a wordpress post, added an image, and it generated a srcset. Every image had the same aspect ratio. What am I missing? Can you show me an example of the issue you're seeing, because if Wordpress is doing that, it's a bug, and I'd like to get them to fix it.
What are the register image sizes in WP?

Also, have to uploaded any images that might not satisfy the necessary dimensions.

If WP was doing it correctly all the time there would be a question or two per week about images in the various WP groups I'm in.

At the end of the day, you can have rules for WP cropping / resizing images. But those don't necessary guarantee the dimension of the image output from that. And WP certainly isn't checking each any every image for it's actual dimensions.

And WP aside, it just doesn't make sense any output from a CMS is going to exactly what you expect. object-fit is a fail-safe. Object-fit is also smarter and better than a fixed size background image.

The article has a narrow-ish use case.

Am I blind? In the first link, I don't see anything there that demands the images all have the same aspect ratio.

Regardless, when using WP this isn't going to happen.

Furthermore, even if all the images in the srcset have the same a-ratio, that doesn't mean that ratio is the same as the ratio in the markup + CSS. Yeah, you can assume. But why risk it?

> In the first link, I don't see anything there that demands the images all have the same aspect ratio.

It says "the smaller image is a scaled-down version of the bigger image". If you scale an image down evenly, it will have the same aspect-ratio. In case you're going to pick at the wording: I know that it's the intention of the spec authors and browser implementers that all entries in the srcset have the same ratio.

> even if all the images in the srcset have the same a-ratio, that doesn't mean that ratio is the same as the ratio in the markup + CSS. Yeah, you can assume. But why risk it?

The last section of the article discusses this.