41–49 of 49 posts
You always want to have the image loaded before you actually use it. You don't want to wait until you actually use the image. For instance in a carousel, you'll want to load the next and previous image, not just the current displayed one.
I'd much rather have a "loading order" than lazy loading. Sure, I don't want to load first the big images that I'll want to display later, but I definitely don't want them to appear while I scroll down...
For anyone hearing about loading=“lazy” for the first time from this article , I’ll reiterate the main idea because the article doesn’t go into much depth about the motivation. The main idea is that some pages use a lot of cellular data to load images that are further down the page, out of the viewport. If the user glances at the page and decides it’s not relevant and exits, then those offscreen images were just a wa…
This is a poorly thought feature. You always want to have the image loaded before you actually use it. You don't want to wait until you actually use the image. For instance in a carousel, you'll want to load the next and previous image, not just the current displayed one. I'd much rather have a "loading order" than lazy loading. Sure, I don't want to load first the big images that I'll want to display later, but I de…
There's an FAQ about carousels, too:
https://web.dev/native-lazy-loading#how-does-the-loading-att...
> How does the loading attribute work with images that are in the viewport but not immediately visible (for example, behind a carousel)? > > Only images that are below the device viewport by the calculated distance load lazily. All images above the viewport, regardless of whether they're immediately visible, load normally.
I'm happy to see this. So many websites with lazy loading never implemented a fallback for noscript. And most of the popular libraries didn't account for this accessibility.
just curious -- in what situation would your average user not have javascript turned on?
Earlier quoted context omitted.
Maybe it was just done out of habit. A bool can be expected today. But why about 10 years from now? Defensive programming isn't a bad thing. Making assumptions is why we had the Y2K mess.
That's an unreasonable, excessive use of defensive programming. We're not talking about an unstable API here, we're talking about an operator. It would be just as unreasonable to "defend" your code against `1 + 1` suddenly returning a boolean rather than a number.
Ignore the symbols and use the words. Which makes more sense to you?
"[My test] strictly equals true." or "[My test] loosely equals true."
Earlier quoted context omitted.
Maybe it was just done out of habit. A bool can be expected today. But why about 10 years from now? Defensive programming isn't a bad thing. Making assumptions is why we had the Y2K mess.
That's an unreasonable, excessive use of defensive programming. We're not talking about an unstable API here, we're talking about an operator. It would be just as unreasonable to "defend" your code against `1 + 1` suddenly returning a boolean rather than a number.
I wish there was a middle ground... detect I'm on WIFI and go ahead and load in the lazy stuff after the above the fold stuff.
Earlier quoted context omitted.
just curious -- in what situation would your average user not have javascript turned on?
It's becoming more common as people use aggressive blockers but the main reason to care about it is that JavaScript breaks fairly regularly. On LTE, I see pages where a simple HTML display would work but a JavaScript loader failed on first load generally a couple of times a day.