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

@Steve: I think Jake has a good case for not defining it as "document has
been fully parsed", see here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842#c48 - the premise
being that we could get the CSS before the HTML doc is complete, and layout
could happen before DCL.

On the download spec: I think this is up to the UA, we shouldn't dictate
this behavior in the spec. Having said that, this is is an obvious
optimization, and I'm guessing all UA's would do exactly that. See "QoI"
section at the bottom of this comment:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842#c46

-- 

The one outstanding question I do have is this clause:

> The download state of images with 'defer' MUST NOT delay the 'load' event
of the window.

Given that the UA may select not to download the "lazy" image, this makes
sense. However, this will change the definition of load event, as we know
it today, which may skew some existing tools, etc.. That's probably not a
problem, but worth highlighting.

ig


On Sun, Apr 14, 2013 at 1:52 PM, Steve Souders <souders@google.com> wrote:

> 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.
>>
>>
>