W3C home > Mailing lists > Public > public-respimg@w3.org > October 2014

Re: additional download on screen shrinking

From: Yoav Weiss <yoav@yoav.ws>
Date: Thu, 23 Oct 2014 22:54:41 +0200
Message-ID: <CACj=BEgdy+9pcFeNTTzJCvnqezfKm3aF1Y5YYBPWsdthRNs5WQ@mail.gmail.com>
To: John Holt Ripley <john.holtripley@googlemail.com>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>
Yeah, that behavior is (intentionally) not specced, and left to the browser
to do as it pleases.
Current Blink behavior where smaller resources are downloaded when larger
ones are already in the cache is a bug
<https://code.google.com/p/chromium/issues/detail?id=425701> and should be
fixed. Unfortunately, I doubt I can get to that before Chrome 40 branches,
so I don't think it'd be released before Chrome 41.


On Thu, Oct 23, 2014 at 10:18 PM, John Holt Ripley <
john.holtripley@googlemail.com> wrote:

> Hi all,
>
> I'm working with non-art directed images in a responsive layout, and
> noticing that when shrinking the viewport, both Chrome and Opera are then
> additionally requesting the smaller image instead of shrinking the already
> downloaded asset.
>
> Is this the intended behaviour? I couldn't see anything in the spec that
> determines this behaviour, so is it up to browser vendors to determine how
> to handle this? (Or the browser itself to look at network speed and make a
> decision from there?)
>
> I can see the need to request the new asset in art-directed cases (within
> the Picture element for example), but in a simple srcset and sizes
> situation is this additional download beneficial? Is the performance
> implication of rescaling a large image offset by the network request?
>
> Thanks
>
Received on Thursday, 23 October 2014 20:55:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:15 UTC