[4.2] Switch div to img and use the loading attr. [Media Manager images list]#36550
[4.2] Switch div to img and use the loading attr. [Media Manager images list]#36550dgrammatiko wants to merge 10 commits intojoomla:4.2-devfrom
Conversation
|
Should we not just add the |
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? |
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
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. |
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 |
| return this.item.height; | ||
| }, | ||
| altTag() { | ||
| return `Image filename: ${this.item.name}`; |
There was a problem hiding this comment.
@brianteeman any ideas what would be a good alt tag for the images view in the MM?
There was a problem hiding this comment.
ask the accessibility team
There was a problem hiding this comment.
but its currently completely inaccessible so i doubt it matters
|
I'll test this and check styling later today or tomorrow. Thank you!! |
administrator/components/com_media/resources/scripts/components/browser/items/image.vue
Outdated
Show resolved
Hide resolved
…s/browser/items/image.vue Co-authored-by: Quy <quy@fluxbb.org>
Yes, switching to the image element needs some scss fixes
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) |
Pretty sure you can fix this 😉 |
|
I have tested this item ✅ successfully on d903326 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. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36550. |
administrator/components/com_media/resources/scripts/components/browser/items/image.vue
Show resolved
Hide resolved
|
@Quy Same error but different display in Safari: |
|
@laoneo will take over this one |
|
Please test #36930 which is the followup on this one. |





Pull Request for Issue #36533 [Solves 1/3 reported problems, the thumbs and the streaming/paginated response are still valid... ].
Summary of Changes
Testing Instructions
npm cior d/l the package from githubimagesfolderActual result BEFORE applying this Pull Request
All images fetched immediately
Expected result AFTER applying this Pull Request
Images are fetched as they enter the viewport
Documentation Changes Required
No
Ping @laoneo @Fedik @crystalenka