W3C home > Mailing lists > Public > public-respimg@w3.org > September 2013

Re: The lazyload and postpone attribute for images

From: Matthieu Larcher <mlarcher@ringabell.org>
Date: Sun, 08 Sep 2013 23:52:23 +0200
Message-ID: <522CF197.7020609@ringabell.org>
CC: public-respimg@w3.org
Hi Marcos,

Those attributes sound promising.
In particular, the "postpone" one got me thinking.
With the incoming meetup on tuesday, I've been catching up on some 
reading on the subject, and I've been trying to figure out a way to fit 
all the pieces of the puzzle together once more. I haven't been a very 
assiduous reader of the mailing-list lately, so please pardon me if what 
I'm about to propose has already been largely discussed here and didn't 
fit the bill, but here it is :

What about making a mix between Client Hints, the "postpone" attribute, 
and Yoav's proposal from 
http://blog.yoav.ws/2011/05/My-take-on-adaptive-images ?
I like the idea of not cluttering the html with media queries, and 
consider that the responsive aspect of images belongs more to the 
styling than to the content.
It seems to me that we have here all we need to make things work as we 
need. Here's how I see it :

<img src="default.jpg" postpone="ch-srcprefix" class="avatar">
<style>
     .avatar {
         ch-srcprefix: "";
     }
     @media screen and (min-width: 800px) {
         .avatar {
             ch-srcprefix: "big/";
         }
     }
</style>

The postpone="ch-srcprefix" informs the browser that this img should 
have a prefix, and that it shouldn't try to fetch it as long as it 
doesn't have it.
Of course, the prefix should be set as soon as possible. It could be 
declared inline in the <head> section, or provided ASAP in the styles. 
It could eventually be manipulated via javascript too.

Once the postpone requirements are fit (i.e. a ch-srcprefix has been 
set), the browser can trigger the download. It calls 
http://domain.com/default.jpg, passing the CH in the headers. The server 
then sees that a ch-srcprefix hint is set, and adds that prefix to the 
filename in order to find the resource. This allows us to keep the art 
direction on the front side instead of letting the server decide.
If the resource is not found this way, the server falls back to the 
normal URL, without the prefix. Servers that don't handle CH would 
behave like this anyway.

If the ch-srcprefix (or any CH related to that img tag) were to change, 
we could consider making a new request with the updated CH. The server 
would then (optionnaly?) abort sending its previous answer and send the 
content corresponding to the new CH.

For old browsers, this is a normal img tag and an ignored css rule, so 
everything is fine if neither the browser nor the server know anything 
about this, which ensures backward compatibility. But we can have a fine 
grained control via CSS over the parameters we pass along to the server 
with the image request. Of course, those CH could be overriden by the 
browser if needed.

I know a lot of discussions have led to the current picture tag 
proposal, and there might be a dozen reasons why this one wouldn't be a 
plausible solution, but I'd love to have feedback from the group on this 
idea. Please let me know what you think.

--
Matthieu Larcher



Le 06/09/2013 12:16, Marcos Caceres a écrit :
> Hi All,
> Just wanted to bring your attention to some new W3C work [1] called "Resource Priorities" (crappy name!), which is proposing a "lazyload" and "postpone" attribute for images:
>
> [[
> The lazyload attribute indicates the priority order in which the User Agent will download the resource associated with the element in cases of network resource contention.
> …
> The postpone attribute indicates that the User Agent MUST not start downloading the resource associated with the element until either the bounding box of the element is inside the User Agent's interpretation of the Document's viewport, or the element has been styled such that its display property is no longer set to none.
>
> ]]
>
> Please see also the following bug… it's very long and detailed, but provides background to the problem:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842
>
> The RICG should have a stake in this work - so if you have opinions about this, let us know so we can collaborate with the WebPerf WG.
>
> [1] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html--
> Marcos Caceres
>
>
>
>
Received on Sunday, 8 September 2013 21:52:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:40 UTC