I tried to reproduce the bug by he steps mentioned, i.e.m using developer tools of chrom and changing user-agent.
I got the following results which were expected:
iPhone6 loads a 640px banner which is expected:

I can replicate this.
In iPhone6 plus in the ios simulator provided by xcode... in landscape mode it is downloading a 320px banner.

Looking at caniuse, there is only partial support in safari 8 which would explain this.
http://caniuse.com/#feat=srcset
(it only supports the x selector not w)

In the process it would also be good to think about IE if necessary and easier.
Right now pages that do not support srcset are loading 1280px banner - we really need to avoid this.
I would suggest rethinking the fix to I0b659b30b89171a91c70b0e243accf7f0046d1b6 - loading the highest resolution banner is not a good idea. Load the smallest, and adjust with JavaScript when no support to avoid blurriness.

If I use javascript to adjust banner when srcset is not supported, we risk blurry banners in javascript disabled case. Going ahead with the current scenario, we preserve whatever is the status-quo regarding responsive banners, i.e, largest banner when no srcset. I think if a blurry banner is seen even on a single browser, it is a bad experience, whereas taking path of full dependence on srcset would allow excessive bandwidth in some cases for some time, which however would gradually rule out as support for srcset in browsers will increase. However, if you still think that low-res banners be added as default, I'll add a patch.

One of the motivations however was to provide a better experience for mobile browsers - currently they are needlessly downloading huge images for all browsers except Chrome... :-(

I think a middle-res banner would be a good compromise here. What do you think?

(Note, 640px width should be enough for most browsers...)

Yes, agreed, I'll take the middle path of adding a 640px size banner and then manipulating accordingly.

It seems that using javascript together with srcset is a difficulty in itself because I'm unable to see how to determine the image rendered by srcset. The property currentSrc is experimental and works correctly only on chrome. See https://developer.mozilla.org/en/docs/Web/API/HTMLImageElement . Without determining which size banner-image has loaded, its impossible to selectively use javascript to load a proper-size image. Should user-agents be used to decide for selective usage of javascript to serve banners, since we have a fair idea of which browsers support "srcset" and which don't?

Make the SRC attribute 640px. No js needed!

I think it is best we talk about this tomorrow in our meeting (I may be misunderstanding something)

Sample of 640px banner

It might be worth exploring a srcset polyfill for browsers that do not support it. This way with JS you will always see the best possible image.

Change 228785 had a related patch set uploaded (by Sumit):
WikidataPageBanner implement srcset polyfill

https://gerrit.wikimedia.org/r/228785

@Jdlrobson, testing the above patch is difficult for me as all the browsers support "srcset", can you test it on the emulator which reported a problem in the task above?

Wondering if @brion's resources/src/jquery/jquery.hidpi.js jquery library could be used for this purpose... (specifically this is not for retina screens)

So if I'm reading the above comments correctly, these banners want to use the width capping specifications ('w640') in img srcset, but Safari and our JS polyfill only support switching on the device pixel ratio ('2x').

I suppose you might be able to rig up a fancier polyfill (there probably are some out there)... but beware that a JS polyfill will run *after* the browser's already started downloading the image it originally selected, which in this case will be the giant one from the native srcset. So that may not be an ideal solution.

Consider also using a CSS background image which would allow using a @media selector on the screen size, and will work across more browsers...

Thanks @brion for the quick response! You read correctly.

Right now we're using srcset attribute to serve the best sized banner depending on the user's current browser window.
The plan is to point the src attribute to the lowest res image but we're keen to use a nicer image in desktop/tablet browsers without srcset support. I think thus the 2 image downloads is not a big problem here.

css is currently not a solution as the banners are all custom and generated via wikitext and served in an img tag.

Do you think it's worth pulling in a poly fill this purpose?
The other alternative is loading a larger higher quality image on non-mobile browsers that do not support srcset but that seems equally nasty :-/

If http://caniuse.com/#feat=srcset is to be believed, the main problem browser on mobile is going to be Safari on iOS 8, since it supports native srcset but only for density switching, not for the size specifications. So if you use a customized polyfill, you can't rely on the basic test like img.srcset !== undefined...

Probably ok to go ahead and use a customized polyfill for the banners; use data-srcset or something in place of the native srcset attribute so iOS 8 doesn't start downloading the giant image!

I would probably recommend updating jquery.hidpi.js to support width/height specs rather than including a second polyfill.

This is desktop AND mobile so the impact is a little greater.. :-/

Well, desktop isn't as big a worry since high-res screen usually means large screen (and you'll usually max out at 2, rather than the 3 that some phones like the iPhone 6plus reach)... :) So it should be safe there to load the 1x and then polyfill-load the native-density-except-on-small-screen.

But yeah that code'll have to run on both. Feel free to ping me for review etc

Brion have added you to the patch. I've also moved this to the freezer column since it's not a huge priority right now in my opinion as we get closer to launch.

Change 228785 abandoned by Jdlrobson:
WikidataPageBanner add open-source srcset polyfill

Reason:
Due to lack of activity.

https://gerrit.wikimedia.org/r/228785