Re: The lazyload and postpone attribute for images

Hi Matthieu,

Interesting approach. A few questions:
What's the advantage of using CH here? Under which use-case would the
developer not know if a certain resource exists or not on the server?

I'm also worried with the binding of art-directed images with postponed
images. One of the advantages of the current native proposals is that
they'd perform better than current JS techniques. This method will prevent
that, by forcing the images to wait for layout and be in viewport in order
to start the download.

Regarding the MQs cluttering the HTML, check out [1] for a discussion on
how they can be moved back into CSS land.

See you tomorrow! :)
Yoav

[1] http://lists.w3.org/Archives/Public/www-style/2013May/0638.html


On Sun, Sep 8, 2013 at 11:52 PM, Matthieu Larcher <mlarcher@ringabell.org>wrote:

> 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<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<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--<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html-->
>> Marcos Caceres
>>
>>
>>
>>
>>
>
>

Received on Monday, 9 September 2013 12:21:15 UTC