On Wed, Sep 5, 2012 at 2:00 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:
On Wed, Sep 5, 2012 at 12:35 PM, Asher Feldman
Browser scaling is also at least worth
experimenting with. Instances where browser scaling would be bad are
likely instances where the image is already subpar if viewed on a
/ retina display.
Other instances where
browser scaling is bad are:
* PoS browsers that don't render SVGs (how old are these by now?)
IE up through 8, and Android stock browser through 2.3. Neither are dead
yet, so we still gotta deal with rasterization for them.
* Even modern browsers have subpar SVG rendering at 1x, PNG looks better
Examples? Sounds like bugs need to be filed with some of those browsers. :)
> * Some media types are "scaled" in unusual ways (SVGs, but also video
> stills, PDF pages, ...)
> * Some original images are really friggin' large (20-30 megapixels
> sometimes), so at least some downscaling is needed there
You'd absolutely want to do server-side downscaling to the base sizes in
the appropriate file formats -- we wouldn't try to download multi-megapixel
originals just to make a tiny thumbnail, and some formats require
conversion to a format the browser can read.
For an example if we were to standardize on sizes: (we wouldn't use these
actual sizes because they do NOT fit our usage)
Then somebody requesting a 400px image might get the next size up, the
512px image delivered and scaled down in the browser. (On a high-resolution
display, you might fetch the 1024px image.)
In reality we'd want sizes that fit most common usage, and perhaps make
future markup & visual editor widgets promote using of standard sizes to
minimize the cases where you end up with something that's not an exact fit.
> * Mobile clients will want to minimize the amount of data transferred
This is a good reason for picking appropriate default sizes that would fit
with actual common usage.
Note that with SVG, SVG originals can be either much smaller or much larger
than a rasterized image -- in many cases we have SVGs that are much more
detailed than they need to be. So serving of SVG doesn't guarantee a
bandwidth save, though it can in well-designed cases.
Mobile also has the case that many (possibly even most in some markets)
devices have a greater than 1.0 device-to-CSS pixel ratio, so loading 1.5X
or 2.0X versions of raster images may be something we want in many cases.
In theory you could make a switch -- just as we have a 'disable images'
switch, we could make it a three-way control 'no images - low-resolution
images - high-resolution images'.
[And just to screw with people, Windows 8 / Windows RT is going with 1.4x
and 1.8x scaling factors instead of the 1.5x and 2.0x that Android and iOS
-- and Windows Phone 7 -- use. Fun huh! We're probably not going to have
exact scaled versions of them, they'll get the 1.5 or 2.0 and scale it down
a little probably.]