[whatwg] Features for responsive Web design

[Ashley Sheridan]

On Sat, 2012-10-13 at 06:04 +0000, Fred Andrews wrote:

> 
> > From: mjs at apple.com
> ...
> > > My point is, that any device-specific notation, such as "2x", forces the author to make decisions that the browser should actually make. The author does not know if in a few years the image will be viewed with 1.5x or 3x or 7x or whatever devices.
> > > 
> > > This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as:
> > > 
> > > srcset="low.jpg 200w, hi.jpg 400w, huge.jpg 800w"
> > > 
> > > Where "200w" is the actual image width and not the viewport width. Like that every browser can decide which source to load based on the display, and available bandwidth or user setting or whatever.
> > 
> > The benefit of declaring a scale factor is that the browser can rescale each version of the image to be a consistent size in CSS pixels. Declaring the width of the image does not tell the browser how much that version should be scaled. The browser could guess based on ratios between the different specified widths, but it seems like that would make the problem you describe worse - the author would still have to understand device pixel densities but would only be able to specify them to the browser in a mysterious and indirect way.
> 
> This does seem to be an important point.  Would the follow be a correction understanding of your point: if there are a range of images each with a different declared size and the CSS pixel size of the image is not constrained then the browser must use the image pixel size to determine the CSS pixel size and without knowing the density then this can not be done uniquely?
> 
> Perhaps the 1x density image could be placed first in the list, and then the densities would all be defined. Having the widths declared may have an advantage when the CSS pixel size
>  of the image is known before the image is loaded because in this case 
> the appropriate image can be determined without needing to load an image
>  to read the size.
> 
> Alternatively perhaps rather than interpreting the density multiplier as a media query, it could be viewed as a density scaling factor, with the 1x scaling image being the default hint for a 1x density display.  The browser would then be free to choose to use any available image as necessary and may reload a different image if the image box size changes or upon zooming.
> 
> Then again, perhaps I have misunderstood your point.
> 
> For fluid design the elements are typically designed to adapt to the available size and having to include media query viewport widths in the srcset is equally problematic - a designer knows the images sizes but does not want to be thinking about the viewport widths.  A fluid design would probably have little or no media queries based on the viewport width.
> 
> cheers
> Fred
> 
>  		 	   		  


Just using the image dimensions isn't enough to for a browser to
determine what might be best used on a low bandwidth connection. A JPEG
image of the same pixel size could be saved out with varying degrees of
compression. This won't matter in the case of interlaced images
(although that penalises higher bandwidth connections). One alternative
would be to 'lie' to the srcset declaration by saying an image is a
pixel or two shorter in one dimension to trick it into downloading the
"better" resource. The other alternative might be to include a (rough)
file size in the srcset declaration:

srcset="low.jpg 200w 500B, hi.jpg 200w 1k, huge.jpg 200w 2k"

It does have a problem, namely that this sort of information isn't
always known (a CMS that doesn't deal with images, images source via
file repositories, images being updated after any HTML is created, etc)
but in cases like that the file size could just be omitted (it is only a
hint anyway).

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk