Page MenuHomePhabricator

Issues with srcset with browsers that do not properly support it
Closed, DeclinedPublic

Description

On English wikivoyage Traveller's pub, Ryan notes

I opened http://pagebanner.wmflabs.org/wiki/Culver_City in an iPhone 6 emulator and the banner image is still the 2100px image. Is that expected? I thought part of the functionality was to have smaller banners downloaded on smaller screens?...
I saw the issue using the most current version of Chrome after using the developer tools to change my user agent to iPhone 6. I use this method for testing different mobile browsers frequently at work.

Event Timeline

Sumit created this task.Jul 22 2015, 2:48 PM
Sumit raised the priority of this task from to Needs Triage.
Sumit updated the task description. (Show Details)
Sumit added a project: Wikidata-Page-Banner.
Sumit moved this task to Blocked on the Wikidata-Page-Banner board.
Sumit added a subscriber: Sumit.
Restricted Application added a project: Wikidata. · View Herald TranscriptJul 22 2015, 2:48 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Sumit updated the task description. (Show Details)Jul 22 2015, 2:48 PM
Sumit removed a project: Wikidata.
Sumit set Security to None.
Sumit added a comment.Jul 22 2015, 2:51 PM

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:


iPhone6 plus loads a 1280px banner which is expected due to its device-pixel ration being 3:

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.

Jdlrobson renamed this task from Possible issue with srcset? to Issues with srcset with browsers that do not properly support it.Jul 22 2015, 4:54 PM
Jdlrobson triaged this task as High priority.
Jdlrobson moved this task from Blocked to June 26-July 18 on the Wikidata-Page-Banner board.
Sumit added a comment.Jul 27 2015, 7:09 PM

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...)

Sumit added a comment.Jul 27 2015, 8:19 PM

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

Sumit added a comment.Jul 27 2015, 8:42 PM

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)

Sumit added a comment.Jul 28 2015, 2:44 PM

Sample of 640px banner


Sample of 1280px banner

A 640px banner still gives a bad impression on a large screen. Given that full-width banners are 2100px, using a banner in size range 1000-1200px as a default one would be appropriate. It would both save half the bandwidth compared to full-size banner and not compromise with the appearance as well.

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

Sumit added a comment.Aug 3 2015, 1:17 PM

@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?

Jdlrobson added a subscriber: brion.Aug 5 2015, 5:38 PM

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)

brion added a comment.Aug 5 2015, 6:48 PM

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 :-/

brion added a comment.Aug 6 2015, 6:31 PM

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.. :-/

brion added a comment.Aug 6 2015, 6:49 PM

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.

brion added a comment.Aug 6 2015, 6:49 PM

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.

Jdlrobson moved this task from Backlog to Epics on the Wikidata-Page-Banner board.Aug 30 2015, 5:02 PM
Jdlrobson changed the task status from Open to Stalled.Sep 28 2015, 11:28 PM
Jhernandez lowered the priority of this task from High to Low.May 25 2016, 4:20 PM
Jhernandez moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.
Jhernandez added a project: patch-welcome.

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

Reason:
Due to lack of activity.

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

Jdlrobson closed this task as Declined.Jul 17 2017, 9:51 PM
Jdlrobson moved this task from Backlog to Blocked on the Readers-Web-Backlog (Tracking) board.

Ios8 is kinda old now. Given lack of activity I suggest we don't fix this.