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

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

From: Alexander Farkas <info@corrupt-system.de>
Date: Sun, 05 Oct 2014 21:06:43 +0200
Message-ID: <543196C3.3010500@corrupt-system.de>
To: public-respimg@w3.org
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
Received on Monday, 6 October 2014 13:16:43 UTC

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