Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yall.js as a fallback for native loading="lazy" #75

Closed
panablue opened this issue Dec 2, 2019 · 3 comments
Closed

yall.js as a fallback for native loading="lazy" #75

panablue opened this issue Dec 2, 2019 · 3 comments

Comments

@panablue
Copy link

panablue commented Dec 2, 2019

Now that a significant segment of browser market share supports native lazy loading with loading="lazy", what's the best way to configure yall.js as a fallback?

Something like:

if ('loading' in HTMLImageElement.prototype) {
    // Remove "data-" prefixes?
}
else {
    // yall.js inline here
}

(LazyLoad includes a native/fallback option, but although lightweight, ideally the full plugin would only be loaded when native lazy loading is unavailable.)

@malchata
Copy link
Owner

Thanks for this, @panablue.

At current, my strategy is no fallback. I considered writing a new version of yall to try and dovetail with native lazy loading, but the more I think it over, the more I'm convinced that one of two strategies should be adopted:

  1. If one wants full coverage across browsers for native lazy loading, then using a JavaScript-based solution (yall or otherwise) in the documented fashion might be preferable to juggling both it and native lazy loading.
  2. If one wants native lazy loading, progressive enhancement is preferable. Browsers that can support it will use it, those that don't, won't.

Native lazy loading is currently supported for images and iframes in nearly 63% of browsers at the time of this writing. As Edge creeps forward with adoption of Chromium, and Firefox appears to show interest in implementation, I'm less inclined to believe we should be pressing forward with userland solutions like this. I believe they ultimately hold the platform back, and introduce unnecessary complexity in applications in the presence of a simpler, more robust platform-provided solution.

@daytonlowell
Copy link

WebKit is working on it. https://bugs.webkit.org/show_bug.cgi?id=196698

@panablue
Copy link
Author

@malchata Just going with one or the other certainly keeps it simple. Depending on the region and site-specific audience (prevalence of iOS, etc) I suppose sticking with a JS solution for now probably covers the most users.

If it's useful to anyone, this is a simple snippet I put together for a recent project that didn't need support for srcset or CSS background images. It removes the data- prefix in browsers that support native loading="lazy" or dont' support IntersectionObserver (very old browsers) and falls back to IntersectionObserver for everything in between:

var lazyimages=document.querySelectorAll("img[data-src]"); if("IntersectionObserver"in window&&!("loading"in HTMLImageElement.prototype)){var imageObserver=new IntersectionObserver(function(entries,observer){entries.forEach(function(entry){if(entry.isIntersecting){var image=entry.target; image.src=image.dataset.src; image.removeAttribute("data-src"); imageObserver.unobserve(image)}})},{rootMargin:"500px 0px"}); lazyimages.forEach(function(image){imageObserver.observe(image)})}else{for(var i=0; i<lazyimages.length; i++){lazyimages[i].src=lazyimages[i].dataset.src; lazyimages[i].removeAttribute("data-src")}}

Used with HTML like:

<img src="data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20IMAGEWIDTHGOESHERE%20IMAGEHEIGHTGOESHERE'%3E%3C/svg%3E" data-src="REALIMAGEPATHGOESHERE" width="IMAGEWIDTHGOESHERE" height="IMAGEHEIGHTGOESHERE" alt="ALTTEXTGOESHERE" loading="lazy">

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants