Re: The lazyload and postpone attribute for images

Hi Yoav,

Thanks for your feedback. Here's a few answers to your questions :

CH is here used as a way to add "meta-data" to the resource request. The
way I see it, that's what we really need : we want to be able to "bend" the
image request (the content) so that it fits the art direction choices
defined in the CSS (the style) for the device capabilities and overall
layout position (the context).

The developer should indeed know if a certain resource exists on the
server, but if for some reason it isn't there anymore, we have a natural
way to provide the default image as a replacement for the contextual
content, so we might as well use it.

About the postpone attribute, I kind of made my own interpretation of it :
my suggestion isn't for images to wait for being in the viewport, as the
postpone attribute currently specifies. I use that attribute to specify the
postponing conditions. I believe that "being in the viewport" is only one
condition that could occur, and that "having a ch-srcprefix set" could be
another. So the image loading would be only delayed until some CSS rule
sets a ch-srcprfix for that image. That's also why I suggested a modus
operandi for a ch-srcprefix change : as we know, CSS rules can override
each others, and device orientation or DOM changes can impact the styling
rules.

I understand that images prefetching is a very important performance issue,
but I can't help thinking that we could still delay it a bit in order to
get the correct content.
What good is image prefetching if it's not fetching the correct image ?
What good is having applied a "separation of concerns" approach to websites
if we end up stuffing media queries in the markup in order to support
browser vendor optimizations ? Nowadays, many web developers end up finding
hacky ways to disable images prefetching altogether in order to achieve a
responsive solution (think image source replacement of a blank.gif or more
radical solutions like the plaintext tag halting everything in Mobify.js).

I'm sure we can find some middleground that would be profitable to everyone
(the browser vendors, the developers, the content editors and the end
users—in reverse order). And I hope that this solution will be as "future
proof" as possible.

See you tomorrow,

--Matthieu Larcher


2013/9/9 Yoav Weiss <yoav@yoav.ws>

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