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

On Tue, Apr 16, 2013 at 8:16 PM, James Simonsen <simonjam@google.com> wrote:

> This is why I put a lot of wiggle-room here. For mobile connections &
>> different thread scrolling. The viewport visibility bit is the very latest
>> that images should be downloaded.
>>
>
> My point on these is MUST and MUST NOT don't provide any wiggle room.
>

Is there a particular MUST or MUST NOT that you disagree with? The wiggle
room is the browser can start downloading an image any time between it
being in the DOM & not display:none, and in the viewport. The current spec
is the browser MUST download the image as soon as the element is
constructed, far less freedom.

"being in the DOM & not display:none" - this is to avoid downloading hidden
imagery & allow JS to modify
"in the viewport" - this is common sense really. Just speccing that images
should be considered a non-optional part of the intended rendered output.


> This wouldn't cover the JS-polyfill case, and cases like a carousel of
>> images where many of them are unlikely to load for most users.
>>
>
> Why not? Why don't you want the browser to download the carousel images if
> it's idle and bandwidth is cheap? It's strictly better to, in case the user
> does click on the carousel.
>

I see your point on the carousel. In reality you would keep the images
visible, but visually hidden by being in the non-visible parts of an
overflow:hidden element. The browser would download these images with lower
priority.

So, would you rather the CSS asset loading stuff was opened out so the
browser could download imagery/fonts that weren't on the page?

Still need the display:none case for image polyfills through.


> And it's no worse than how carousels work now, where everything is
> downloaded at once and interferes with other images.
>

 That sounds a lot worse to me. Visible assets are queued behind
non-visible assets.