W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] Deferring image load

From: Kang-Hao <kennyluck@csail.mit.edu>
Date: Mon, 13 Feb 2012 19:00:52 +0800
Message-ID: <4F38ED64.8040408@csail.mit.edu>
(12/02/13 18:33), Bjartur Thorlacius wrote:
> On 2/13/12, Gray Zhang <otakustay at gmail.com> wrote:
>>    1. On a product description page of a shopping site, there are several
>>    *main* pictures of the product, along with about twenty or so camera
>>    pictures of the product taken from different angles. When the HTML is
>>    parsed, browsers by default simultaneously start downloading all images,
>>    potentially making some of the *main* ones invisible.
> Hmm. So you request a way to declare which images are important, and
> wich are not?

For this particular use case, yes, I think so. I do think this use case
has very different characteristics from the other two although currently
they are solved by similar technique.

>>    2. On an album page where hundreds of pictures are expected to be shown,
>>    it is often required that pictures currently in a user's screen should
>>    appear as fast as possible. Loading of a picture outside the screen can
>> be
>>    deferred to the time that the picture enters or is about to enter the
>>    screen, for the purpose of optimization user experience.
> This seems like something interactive user agents should implement.

But it is currently not reliable to the extent that Web authors can rely
on it. The current spec for <img>[1] says

  # User agents may obtain images immediately or on demand.

Is there actually an existing user agent that obtain images on demand?

>>    3. a global switch as a http header or an attribute on html to switch
>>    UAs image loading from "obtain images immediately" to "obtain on demand"
>> or
>>    vice versa.
> Would this not depend equally on factors such as whether the user
> agent would download the images over a metered connection?

Could you elaborate a little more on this? What is a metered connection?


Received on Monday, 13 February 2012 03:00:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC