[whatwg] Features for responsive Web design
mjs at apple.com
Fri Oct 12 21:17:04 PDT 2012
On Oct 11, 2012, at 11:07 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Am 11.10.2012 18:36 schrieb Ian Hickson:
>> On Thu, 11 Oct 2012, Markus Ernst wrote:
>>> IMHO as an author, the "bandwidth" use case is not solved in a future
>>> proof manner
>> It's not solved at all. I didn't attempt to solve it. Before we can solve
>> it, we need to figure out how to do so, as discussed here (search for
>> "bandwidth one"):
> It looks like my English is not perfectly understandable, I am sorry I am not a native English speaker. I did not try to state the use case was solved. I have been following the discussion in this list quite closely.
> 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.
More information about the whatwg