Re: <img src="..." defer>

On Tue, Apr 16, 2013 at 1:44 AM, James Simonsen <simonjam@google.com> wrote:

> For instance, you don't want the browser to constantly recompute style for
> every little change just so that it can decide whether or not to start
> fetching a deferred image.
>

I don't think we need any more style computation than we already have. We
already use it to decide when to show CSS backgrounds, we'll be checking
images at the same times.

Likewise, spec'ing "visible within the viewport" is dangerous with modern
> browser rendering architectures. Visibility is often determined by a
> different thread or process entirely for the sake of smooth scrolling. I
> think it'd be better to just say deferred images should be fetched when
> convenient for the browser. We know we should focus on getting the onscreen
> ones first. :)
>

This is why I put a lot of wiggle-room here. For mobile connections &
different thread scrolling. The viewport visibility bit is the very latest
that images should be downloaded.


> I also don't think it's worth spec'ing the display:none criteria. If the
> image is deferred, the browser now has the option of not loading it at all.
> This was never a choice before. So, if now we don't _need_ to load an
> image, we can try to figure out whether or not we _should_ load it. For
> instance, if we can decide a display:none image would only become visible
> on a phone's viewport, and we're on desktop, we can skip it. Or if we're
> not sure how it would become visible, and the network is idle and cheap, we
> can speculatively load it anyway. Even if we guess wrong and skip something
> that'll be needed, we'll still fetch it when it comes into view, making it
> no worse than "scrolled into view" situation.
>

This wouldn't cover the JS-polyfill case, and cases like a carousel of
images where many of them are unlikely to load for most users.


> Another important thing to keep in mind is that older browsers will fall
> back to their default behavior, which is to ignore the new attribute and
> fetch everything and block the load event. I think that's fine, because it
> fails in a way that will still work correctly, if slower.
>

Yeah, old browsers get the current behaviour. Don't see that being an issue
other than less optimal.