Should we not just add the loading="lazy" attribute to the image tag as the dimensions are available for the images. We should use the platform as much as possible said once a Joomla JS developer (can't remember his name ? ).

Should we not just add the loading="lazy" attribute to the image tag as the dimensions are available for the images. We should use the platform as much as possible said once a Joomla JS developer (can't remember his name ? ).

There are no img tags in the media manager currently - all images are loaded as background images of div elements.

What is the benefit of loading them as background images?

We should use the platform as much as possible said once a Joomla JS developer (can't remember his name ? ).

This sounds obnoxious. Why would you ever want to use the browser's provided APIS instead of building them again and having a gazillion of bugs?

Joke apart the loading=lazy is an attribute for the img element and as @crystalenka already mentioned the design is asking for a style="background-image: ..."

What is the benefit of loading them as background images?

No alt (obviously this is an a11y problem) and it was easier to style/append the edit buttons/checkbox on top (?)

I have absolutely no idea, it seems inefficient to me but I'm not sure. Just commenting why lazy loading wouldn't work as the media manager works now.

No alt (obviously this is an a11y problem) and it was easier to style/append the edit buttons/checkbox on top (?)

How wonderful it would be to manage alt text globally! But this is beyond the scope of this issue/pr, haha.

I am happy to help style the edit buttons over the top of inline images if that is more efficient/a necessary change.

Ok, switched to the image tag and used the loading attribute. The styling is a bit of but some object-fit: contain; or something similar should get us back to the previous state (design-wise). @crystalenka @laoneo

I'll test this and check styling later today or tomorrow. Thank you!!

I first test shows the attributes loading, width and height in the image. But they are loaded initially in the network tab on FF and chrome.

Additionally has the image container not the same dimensions as the folders:

Additionally has the image container not the same dimensions as the folders:

Yes, switching to the image element needs some scss fixes

I first test shows the attributes loading, width and height in the image. But they are loaded initially in the network tab on FF and chrome.

If you roll to 87d01f8 you'll see that the intersectionObserver is a better fit here. The reason is that there's something weird with the zoom-in/out functionality that triggers the browser to always consider more images in the viewport than what's actually there. Didn't spend any time figuring out what's triggering this (container or item size, or anything else)

The reason is that there's something weird with the zoom-in/out functionality that triggers the browser to always consider more images in the viewport than what's actually there. Didn't spend any time figuring out what's triggering this (container or item size, or anything else)

Pretty sure you can fix this ?

I have tested this item ✅ successfully on d903326

If you add the following CSS rules to .image-cropped it fixes the styling issue in modern browsers:

aspect-ratio: 1/1;
object-fit: contain;

Aspect ratio is supported in most recent releases of most modern browsers (https://caniuse.com/?search=aspect-ratio), I'm not sure what J4 is supposed to support but if necessary I can do this a different way. This is just the most future-proofed way to do it.

SVG not displaying correctly.

<img class="image-cropped" src="undefined?1641936364457" alt="brand-large.svg" loading="lazy" width="0" height="0">

@Quy
Same result as you in Firefox and Chrome

Same error but different display in Safari:

@laoneo will take over this one

Please test #36930 which is the followup on this one.