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

I support a way to delay-load images with HTML markup. Yay!

I'm okay with bikeshedding "defer" - I think it's similar enough - but I'm
totally okay with a different name. Not to tangent this discussion but when
choosing the attribute name we should keep in mind that we need ways to use
markup to lazy-loading everything (stylesheets, iframes, etc.). It would be
good to think of other scenarios and see if there's a naming convention
that works best.

We need a spec for how these images are prioritized for downloading. For
example, if a website has a mixture of images that are more & less
important all on the same domain and the less important ones are marked
"defer", it would be ideal if the images marked "defer" did *not* block the
more important images. I would specify "images marked "defer" are not
downloaded until after the HTML document has been fully parsed".

-Steve



On Sun, Apr 14, 2013 at 12:31 PM, Yoav Weiss <yoav@yoav.ws> wrote:

> Regardless of attribute name (on which I don't have a strong opinion), I
> support this proposal. It covers the major use cases for image deferral &
> facilitates use of JS to implement minor use cases.
> +1
> The use cases here sound great to solve.
>
> The main concern I have is a bikeshedding one. The 'defer' behavior
> described here is quite different from how <script defer> works (it
> makes the load happen unconditionally as soon as the main HTML has
> downloaded, no sooner and no later).
>
> So I wonder if we should use a different attribute name.
>
> / Jonas
>
> On Sun, Apr 14, 2013 at 7:52 PM, Jake Archibald
> <jakearchibald@google.com> wrote:
> > Hi,
> >
> > I know this group is looking at resource priorities, but I'm interested
> in
> > taking it a big further for images, and perhaps other visual media such
> as
> > video.
> >
> > # Problems I'd like to solve:
> >
> > Developers are using hacks or ending up with unnecessary downloads when
> they
> > use JavaScript to change the src of an image, but want to provide a
> non-JS
> > fallback (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842).
> > Although this particular case will be solved with something like srcset,
> > there are other cases like conditionally using an image format with
> limited
> > support.
> >
> > Developers are using hacks to lazy-load images that are likely to be
> outside
> > the viewport initially. These hacks use heavy scroll listeners and don't
> > take the connection type into account.
> >
> > Images within elements that are never shown are downloaded.
> >
> > # "defer" behaviour:
> >
> > Images with 'defer' MUST NOT download while they aren't in a document, or
> > their calculated 'display' style property is 'none'.
> >
> > The download state of images with 'defer' MUST NOT delay the 'load'
> event of
> > the window.
> >
> > Images with 'defer' MAY download once they are in the document, and their
> > calculated 'display' style property is not 'none'.
> >
> > Images with 'defer' MUST download once they are in the document, and
> their
> > calculated 'display' style property is not 'none', and any part of the
> image
> > would be visible within the viewport. If visibility within the viewport
> is
> > uncertain (due to element size determined by image dimensions), the image
> > MUST download.
> >
> > There's been a lot of discussion on
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842, I'll try and sum
> up
> > the pros & cons but will ping Ilya to add anything I may have missed.
> >
> > # Pros
> > * Imagery in hidden elements that may never be seen by the user aren't
> > downloaded
> > * JS can modify the src of images before their original src downloads, by
> > initially hiding the image with CSS
> > * The browser gets more freedom in regards to image downloading,
> allowing it
> > to do the best thing given the user's connection type & interaction. Eg:
> > ** If making a connection is cheap & quick (eg, fast wifi), the browser
> may
> > delay downloading imagery until it's in the viewport, which can avoid
> > unnecessary downloads way below the fold
> > ** If making a connection is expensive & slow (eg, 3g), the browser may
> > download all imagery that isn't calculated display:none to avoid waking
> the
> > radio up later and using up battery
> >
> > # Cons
> > * When creating images with js, you'd need to set .defer to true before
> > setting .src, else the image would download straight away
> >
> > I don't see this as a big problem, devs know the ordering matters, you
> > already have to set src after load events
> >
> > * Deferred images cannot be downloaded early by preloaders unless they
> > calculate page styles & images that are at the top of the page may
> download
> > later as they need to wait for style calculation to know if they should
> > download or not
> >
> > Not a big deal. Images are low priority downloads anyway compared to JS &
> > CSS so waiting for layout isn't a problem. Also, primary imagery
> shouldn't
> > use this attribute.
> >
> > * Firing the load event before all images download may skew metrics
> >
> > By putting 'defer' on an image you're saying it isn't required to
> consider
> > the page loaded. I don't think this is an issue.
> >
> > * Lazy-loading isn't good on mobile connections
> >
> > The browser isn't required to lazy-load. It can make the choice based on
> the
> > connection, which is far better than the hacky JavaScript developers are
> > using to currently perform lazy-loading.
> >
> > * Developer can't indicate they'd rather have aggressive lazy-loading, to
> > save CDN costs
> >
> > Feature, not a bug. Would rather the browser did what's best for the
> > connection type. The developer could always display:none the images, and
> use
> > a scroll listener to show them as they come into view, but I wouldn't
> want
> > to make that any easier.
> >
> > Cheers,
> > Jake.
>
>