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.
- Trevor
On Tue, Sep 18, 2012 at 8:47 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:
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 ?
In which case we probably need to think more abut minimising this initial
load. I'd suggest not setting the src attribute and using a noscript tag
repeating the same html. We might even be able to write javascript that
parses the noscript tag and creates the new image above it...
Another common trick I've seen is the browser via javascript reporting that
they now have a 2.0x density display and then the php script serving these
as the default in future.
With regards to Daniel's email it might be worth supporting a polyfill such
as [1]. I'm still anxious that since no browsers have implemented it there
might be a few minor changes and I think working with an established
library will keep us up to date.
I think we should be defaulting to true. I agree with Daniel that
experimental features never seem to enabled and don't get properly tested.
This should be the norm. We should be bold! :)
[1]
https://github.com/scottjehl/picturefill
On Tue, Sep 18, 2012 at 12:31 AM, Brion Vibber <brion(a)pobox.com> wrote:
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
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l