On Mon, 19 Mar 2012 17:30:24 -0700, Brion Vibber <brion(a)pobox.com> wrote:
I've been fiddling with a new iPad, with its
notoriously high-resolution
display (2048x1536, roughly similar to the iPhone 4's earlier 2x
resolution
jump on the small screen but on something "real" sized). Text renders
stunningly sharp. And you know what else?
SVG.
Graphics.
Look.
Totally.
Awesome.
On this screen!
I've got a little user script which replaces rasterized SVGs with their
scalable originals:
https://en.wikipedia.org/wiki/User:Brion_VIBBER/hidpi.js
even without fixing up any of the pure-raster images yet, this gives a
visible improvement to pages containing maps, flags, site icons, etc
which
are often SVG.
Similar resolution screens will likely be coming to laptops sooner than
later, so we should definitely start looking into making our UI and our
images look awesome. (It'll also tend to help when printing or zooming in
in the browser -- for instance zoom in on the tables at
https://en.wikipedia.org/wiki/Olympic_Games#Host_nations_and_cities and
you'll actually see the flags, not just blurry little piles of pixels.)
I've filed a bunch of bugs about low-resolution PNG and GIF icons in our
user interface, under the high-density tracking bug:
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=32101&hide_res…
over time we should make sure that our UI is consistently scalable; using
native SVG icons with fallback PNGs should do.
We'll have to do some experiments to determine a good way of doing
fallbacks, deciding when to render things out fully, etc. It may make
sense
to have some per-image controls -- for instance files that are known to
render very slowly we might prefer to serve as rasters; non-SVG drawings
may also benefit from loading at higher resolution on high res displays.
Anyway, more fun stuff for people to think about. :)
-- brion
CSS image fallbacks may be a little annoying.
Last time I checked browsers don't consider "I don't understand that image
filetype." an invalid url(). In other words in:
background-image: url(foo.png);
background-image: url(foo.svg);
Every browser jumps to url(foo.svg) and the ones that don't understand
.svg's choke.
I in css3-images image() notation was defined supporting fallbacks in such
a way that we could use:
background-image: url(foo.png);
background-image: image(foo.svg, foo.png);
Then older browsers would consider image() invalid and use the
url(foo.png) with the png. While browsers with image() support would use
image(foo.svg, foo.png) and following the rules for image() would use the
.svg and if they don't support the .svg would fall back to the .png
automatically.
Of course..... no-one has bothered to implement even basic support for
image().
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [