Page MenuHomePhabricator

Use <img> tag instead of <span> as the placeholder for lazy loading
Closed, DeclinedPublic



  • Lazily loaded images use an img element as the placeholder.
    • Ensure that the loading indicator is displayed in the center of the placeholder as before (see T159477#3076149).
  • The front-end code handles cached HTML.

If we use <img> tag as the placeholder, instead of using <span> as the wrapper, the content would be more correct semantically, and slightly smaller DOM after expansion.

We only need to hide "src" and "srcset" to their data- counterparts, but not other attributes like alt, width, and height.

This is also the way most content sites do the lazy loading.

This would also give various offline tools better hints on how to special-case lazily loaded images. DOM distiller for Reading List in Chrome would be one example.

Event Timeline

wychen created this task.Mar 2 2017, 8:20 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 2 2017, 8:20 PM

I certainly think it's worthy of investigation. @Jdlrobson: What were the reasons for using a span element as the placeholder originally?

I think using an img and moving src to data-src and srcset to data-srcset was my initial approach. I think we swapped to a span containing an img in order to position the loading indicator vertically centered as Design wanted. How would we accomplish the same loading state with the img?

wychen added a comment.Mar 6 2017, 4:40 PM

We can still keep the <span> as the container for the loading indicator. It could be something like

<span><img data-src="..." ...></span>

before expansion, and

<span><img src="..." ...></span>

in the end.

This way, the attributes belonging to the final <img> are kept in <img> before expansion, rather than storing in unrelated <span>.

To be valid html it would need to have a src attribute with dimensions so we can detect when it is scrolled to. We could of course use a data uri to avoid network requests but this will bump up the bytes (although should be swallowed by gzip) so the html would end up bigger and it's likely some logic will need to change eg. We'd have to replace rather than append to and we'd need to check the processing of image tags doesnt negatively impact our metrics.

what is the motivation for doing this and the perceived advantages? It's certainly something that can be explored but im not clear on the why.

Can you elaborate on the DOM distiller example and how this is stifled by the existing approach?

pmiazga added a comment.EditedMar 6 2017, 9:50 PM

the src="" tag is required, if we want to put lazy-loaded image url into data-src then we need some "preloading" image to put inside src="" attribute

wychen added a comment.Mar 6 2017, 9:52 PM

I'd like to see the DOM state before image loading more semantically correct. Currently there's no hints in the DOM saying there would be an image appearing. Having a place-holding <img> would give out this intention better, even though the src and srcset are incorrect (temporarily). For most mobile-optimized sites, lazy image loading is implemented this way, and some sites add dummy data URI as src to be standard compliant like you suggested.

DOM distiller is a content extraction algorithm, and can be used by features like reader mode or offline reading. A general heuristic is to look for attributes like data-src and use that instead of src, when dealing with mobile-optimized sites. DOM distiller can certainly add Wikipedia-specific rules to get the URLs of these lazy loading images, but it might also make sense to make the DOM more machine readable as well. Without special handling, the extracted content wouldn't have the images, since they don't exist in the DOM.

The above task has been proposed for next sprint. Whether this is a possible solution can be decided as part of that work.

phuedx updated the task description. (Show Details)Apr 11 2017, 5:33 AM
phuedx updated the task description. (Show Details)Apr 11 2017, 8:06 AM
Jdlrobson changed the task status from Open to Stalled.Apr 11 2017, 2:43 PM

@phuedx to be clear I meant T162623 has been proposed for next sprint. I think this task has some good ideas but the solution outlined in T162623 seems to be the one that will alleviate our problems without introducing too much complexity

Jdlrobson closed this task as Declined.Apr 26 2017, 9:52 PM

We've gone with a slightly similar approach (rEMFRa1838d7574d5: Use replaceWith rather than appendTo to add lazy loaded image).
This avoids using invalid HTML (img without scr attribute) while making sure when the image is rendered the HTML stays the same.

Thanks for the idea and thinking about ways to solve it. Hopefully we have seen the end of the lazy loading image bugs.