Re: [whatwg] Features for responsive Web design

> From: mjs@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

Received on Saturday, 13 October 2012 06:04:39 UTC