On Tue, Sep 18, 2012 at 5:31 PM, Brion Vibber <brion(a)pobox.com> wrote: Shouldn't experimental features be defaulting to false till it gets tested a bit?

More recently, tablets and a few laptops are bringing 1.5x and 2.0x density displays too, such as the new Retina iPad and MacBook Pro.

How to load up high-resolution imagery on high-density displays has been an open question for a while; we've wanted this for the mobile web site since the Nexus One and Droid brought 1.5x, and the iPhone 4 brought 2.0x density displays to the mobile world a couple years back. More recently, tablets and a few laptops are bringing 1.5x and 2.0x density displays too, such as the new Retina iPad and MacBook Pro. A properly responsive site should be able to detect when it's running on such a display and load higher-density image assets automatically... Here's my first stab: https://bugzilla.wikimedia.org/show_bug.cgi?id=36198#c6 https://gerrit.wikimedia.org/r/#/c/24115/ * adds $wgResponsiveImages setting, defaulting to true, to enable the feature * adds jquery.hidpi plugin to check window.devicePixelRatio and replace images with data-src-1-5 or data-src-2-0 depending on the ratio * adds mediawiki.hidpi RL script to trigger hidpi loads after main images load * renders images from wiki image & thumb links at 1.5x and 2.0x and includes data-src-1-5 and data-src-2-0 attributes with the targets Note that this is a work in progress. There will be places where this doesn't yet work which output their imgs differently. If moving from a low to high-DPI screen on a MacBook Pro Retina display, you won't see images load until you reload. Confirmed basic images and thumbs in wikitext appear to work in Safari 6 on MacBook Pro Retina display. (Should work in Chrome as well). Same code loaded on MobileFrontend display should also work, but have not yet attempted that. Note this does *not* attempt to use native SVGs, which is another potential tactic for improving display on high-density displays and zoomed windows. This loads higher-resolution raster images, including rasterized SVGs. There may be loads of bugs; this is midnight hacking code and I make no guarantees of suitability for any purpose. ;) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

In VisualEditor we ended up putting all CSS rules that include images in *.icons-raster.css and *.icons-vector.css files, which are loaded dynamically based on the window.devicePixelRatio property. It has it's flaws, but the good thing is that it spares the device from loading both versions. I dislike the approach we are using and am open minded to alternatives, but any solution that makes a client load both isn't really going to work.

Sending more data to primarily empower mobile devices sounds rather counter-intuitive

On Tue, Sep 18, 2012 at 10:15 AM, Martijn Hoekstra < martijnhoekstra(a)gmail.com&gt; wrote: Amount of data, and *when that data comes in*, are distinct things. One other change we've got brewing up for the mobile site is to delay loading of collapsed section content by separating it out to an API request. This gets you loading the initial page *immediately*, then loads up the rest. Same amount of data, but the page above the sections is live and visible and interactive before you load the other stuff. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

It's important to separate supporting retina display mobile and desktop devices. Apple's web site uses the load both method to show off the retina display MacBook - which is more likely to have a faster internet connection and is a more powerful machine in general.

Awesome! Correct me if I'm wrong but the way this is currently written an image for foo.jpg will first load foo.jpg then replace the src attribute for this element then load the image foo-2.0.jpg ?

I've updated the patch to use the 'srcset' attribute as defined in the current HTML 5 working group version, only using the density options and not the width/height options: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-conten… Patch in gerrit: https://gerrit.wikimedia.org/r/#/c/24115/ (core) https://gerrit.wikimedia.org/r/#/c/24147/ (MobileFrontend)

BTW, it seems that a certain mobile phone manufacturer wasn't quite ready for this ;) http://tech2.in.com/news/smartphones/samsung-galaxy-s3-browser-bug-inflates… " According to the researchers, the problem is caused by the srcset HTML attribute, which indicates the size and resolution of images a browser should pick based on the device’s screen size and magnification needed. ... The Galaxy S3’s browser, however, has a bug that makes it download all the images specified in the srcset HTML attribute instead of the ones it needs, resulting in long load times and lots of data usage. For instance, the researchers loaded a Wikipedia page that was only 600 KB when browsed using Internet Explorer, but the page’s size inflated to a whopping 2.1 MB on the Galaxy S3. “This bug significantly affects the Wikipedia performance on 3G were these massive number of requests for image downloads overwhelmed the network and ended up timing out rendering an incomplete page,” the research paper reads. " On Thu, Sep 27, 2012 at 3:45 PM, Brion Vibber &lt;brion(a)pobox.com&gt; wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-conten… alpha may -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Can we get some more detail from them?