> From: m...@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
