Last modified: 2013-10-28 08:33:06 UTC
An academic paper was released yesterday that gained quite a bit of press because it asserted that the Samsung Galaxy S3 browser had a bug in it that caused it to download much more data that it should. Original paper: http://lass.cs.umass.edu/papers/pdf/mbenchlab_iwqos13.pdf Sample news coverage: http://classic.slashdot.org/story/13/05/31/2312239 I believe the authors of the report erroneously concluded that this is a bug with Samsung's browser and it is instead a bug in WikiMedia's implementation of the srcset syntax. The authors wrote: "By looking at the recorded HTML page source, we saw that Wikipedia pages use srcset HTML tags that indicate a list of images to pick from depending on the resolution and magnification needed by the device. It turns out that the S3 browser has a bug and systematically downloads all images in a srcset instead of picking only the one it needs (left most red circles on Fig. 14 show 3 different versions of the same image being downloaded). This can result in a massive amount of extra data download." But that conclusion is likely incorrect because: 1. WebKit has yet to implement srcset <https://bugs.webkit.org/show_bug.cgi?id=110252> 2. Wikimedia has its own polyfill version of the jQuery HiDPI plugin that actually handles srcset, not anything the browser is doing <https://github.com/wikimedia/mediawiki-core/commit/966cda2f802cd6cf08d9b73f75fc4b0e7beab625> I've contacted the authors to determine if they saw anything specifically that indicated that this was a Samsung bug. But it seems most likely this is a problem with the polyfill which is why I decided to submit a bug here as well.
Moving from Wikimedia -> MediaWiki (since it's not a WMF-specific bug). Adding Brion since he wrote the feature and said elsewhere he was poking it.
Per discussion back in June: * the paper was mistaken about native srcset support, it was the polyfill * the paper was mistaken about how many versions of the image were downloaded (only 2, not 3 or 4 as suggested) * the behavior is a known limitation of the polyfill, and is a workaround we're willing to deal with for now Note also: * native srcset support has landed in WebKit nightly <https://www.webkit.org/blog/2910/improved-support-for-high-resolution-displays-with-the-srcset-image-attribute/>; definitely won't make Safari 6.1 but might hit the next release... * native srcset support has not yet landed in Chromium/Blink <http://www.chromestatus.com/features/4644337115725824>
Hello, I'd like to point out that the future of srcset syntax is far from being determined. A recent srcN may be the preferred way forward and replace srcset. In general, using "real" attribute names in polyfills for features that are not yet shipped (and srcset is not yet shipped in any browser by default) is discouraged by the W3C TAG, and is better avoided, since it may interrupt the standardization process. Creating content with not-yet-standard features cements their current syntax and makes it harder to modify them if needed. Would it be possible for you to modify the use of "srcset" with "data-srcset" or similar until things settle down? Thanks in advance, Yoav
