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

Re: respimages js - a new responsible polyfill for responsive images (picture + srcset)

From: Tady Walsh <tadywalsh@gmail.com>
Date: Mon, 6 Oct 2014 15:40:15 +0200
Message-ID: <CAG=SzY6L0j_0zX_2S+nxt8SiDbKOvCgJcUCTSGETsicCa5PHww@mail.gmail.com>
To: Alexander Farkas <info@corrupt-system.de>
Cc: public-respimg@w3.org
That looks fantastic Alex! I look forward to testing it later, but for the
moment, it certainly seems like a very positive polyfill. Agree about
Chrome, it's a shame, but will this change? Not sure anyone can have an
answer to this at the moment.

T

On Sun, Oct 5, 2014 at 9:06 PM, Alexander Farkas <info@corrupt-system.de>
wrote:

>  I just wanted to share my new project respimages (
> https://github.com/aFarkas/respimage) with you. In short:
> It's a heavily refactored and bugfixed version of picturefill, while it
> has some new features and a lot of improvements. There are 2 conceptual
> main differences to picturefill:
>
> 1. src attribute is recommended
> respimages uses some image data loading best practices to compensate the
> problem of doubble requests in polyfilled browsers. As it turns out it's
> not just a compensation, it can be really a speed boost ;)
>
> 2. smarter candidate selection
> Due to the fact, that the polyfill is run in an unknown enviroment
> (unknown bandwidth, cpu, battery, user preferences and so on), I'm trying
> to calculate the tradeoff of loading too much image data vs. too less image
> data.
>
> About both things, I wrote a little bit more, which you can find here:
> https://github.com/aFarkas/respimage/blob/stable/how-respimg-works.md
>
> Additionally, I made a simple proof of conept/performance demo, which yu
> can find here:
> http://afarkas.github.io/responsive-image-race/
>
> In case you find bugs, want to help out or simply want to use it or give
> some feedback, you are always welcome. (
> https://github.com/aFarkas/respimage/issues).
>
> While working on this "smarter candidate selection", I came to the
> believe, that also implementers, which even know they are in a
> highbandwidth enviroment should make some "smarter" candidate selection.
> For my article, I constructed the following "worst case" example:
> http://codepen.io/aFarkas/full/tplJE/ and was very sad about how Chrome
> chooses the best candidate. Really hope such cases will be addressed. Or is
> it useless hoping?
>
> Regards,
> Alexander Farkas
>
>
>
>


-- 
Regards,

*Tady Walsh*

*ie:* +353 86 323 6262
*fr:* +33 6 71 61 07 06

@tadywankenobi <https://twitter.com/tadywankenobi>
http://www.tadywalsh.com
Received on Monday, 6 October 2014 13:41:05 UTC

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