[whatwg] Features for responsive Web design

[Maciej Stachowiak]

On Sep 5, 2012, at 12:07 AM, Fred Andrews <fredandw at live.com> wrote:

> ...
> 
>>> I have always been comfortable with the 'x' part of srcset, but the w 
>>> and h part felt somewhat wrong to me. What you'd really want to consider 
>>> when deciding which image to pick isn't the size of the viewport itself, 
>>> but the size available for the image once the rest of the layout is 
>>> taken into account.
>> 
>> Yeah. That's how I originally designed srcset="", actually, but it was 
>> pointed out to me that that's impossible to implement because at the time 
>> the browsers need to pick an image, they haven't yet gotten the style 
>> sheet so they don't know what the layout will be.
>> 
>> (Note that the media-query-based solutions have the same problem.)
> 
> If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available - this may just be the image CSS pixel size and many of these proposals require this to be included anyway.  

That's not really a viable solution. Many authors take little care i making their pages load fast, but browser implementors still consider it important to load them fast.

> It will also help with backwards compatibility to have the style available.  For example:
> 
> <img style="width: 10em" src="image-320x200.jpg" set="image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k">
> 
> The dimensions here are in image pixels, not CSS pixels.  The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional.

The layout size of that <img> element is not computable until all external stylesheets have loaded, as you have written it.

> In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary).    Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in.

Speculatively loading the wrong image does not strike me as an implementation approach that we'd be interested in.

Page loading performance is very important to users, and therefore to browser implementors. I think it's important to avoid defeating important existing optimizations when adding new features.

Regards,
Maciej