[whatwg] Features for responsive Web design

[Fred Andrews]

...

> > 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.  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.

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.

> > Because of that, I was interested in proposals involving an (optional) 
> > defer attribute, which let you wait until layout can inform the 
> > decision. Then, given accurate meta-data on the images's sizes and 
> > density, it would be possible to pick the optimum one. But of course, 
> > this means waiting, so this isn't generally acceptable and must be opt 
> > it. And I can't put my finger on exactly how that would work either.
> 
> If this is something people want to do, it's easy enough to script. If it 
> turns out that people are often trading the performance for this effect, 
> we can definitely look into adding it as a supported feature, but I think 
> (or rather, browser vendors seem to think) it's more likely that the 
> performance matters more than the convenience.

This does seem like a good complementary idea.  Perhaps it should be only a hint and not restrict browsers from speculate loading an image.

...

> On Wed, 22 Aug 2012, John Mellor wrote:
...
> > So for example "1280.jpg 4x" means that this image is 4 times larger 
> > than the given intrinsic width of 320px. So sure, it would be suitable 
> > for display on a hypothetical 4x display at 320px width; but the browser 
> > also knows that it would be suitable for display on a 2x display at 
> > 640px width, a 1.5x display at 853px width, and a 1x display at 1280px 
> > width.
> 
> This isn't accurate. A trivial example of it not being accurate is a 1000 
> device pixel image that consists of a horiontal double-headed arrow 
> labeled "Five Hundred CSS Pixels". That image is _only_ applicable in a 
> 500 CSS pixel double-density environment. If you sed it in a 250 CSS pixel 
> quad-density environment, it would be wrong.

This example may miss the point.  If an image is to be scaled to 500 CSS pixels then this can be specified independently of the image pixel dimensions.  The browser may even decide to download a much smaller image that is labeled "Five Hundred CSS Pixels" and scale it to the require CSS pixel size for the benefit of low bandwidth devices.

...
> > The art direction use case can be entirely orthogonal. It should be 
> > handled with the w/h descriptors as currently specified. What I'm 
> > proposing would operate after any w/h descriptors have narrowed down the 
> > set of allowable images, and let the browser choose between the 
> > remaining images more intelligently in the case of flexible-size images, 
> > where currently the browser has no idea which to use.
> 
> Could you give a real example of this kind of thing? I'd love to study 
> what kinds of images we're talking about here. None of the examples people 
> posted when we were designing srcset="" were like this.

Here's an example of a webpage with images that scale and for which the aspect ratio of the image frame changes fluidly to fit the window width: http://london.msn.co.uk/

The point might be that the CSS pixel size of the image viewport can be entirely orthogonal to the required image pixel size.  This website could benefit from a set of images with the same aspect ratio but different image resolutions.  It could also benefit from some JS to center and scale these images to keep them centered on points of interest (to avoid cropping off a subject heads) - but again this is orthogonal to the required image sets.
 
> On Sat, 25 Aug 2012, Fred Andrews wrote:
> > 
> > Agreed.  The width and height of the images is what is needed.  The 
> > browser needs to fill pixels so needs to know the sizes of the available 
> > images in pixels.
> > 
> > Forget the x scale descriptions and all the other proposed extensions 
> > and just include a set of images with their pixel height and width.  
> > Forget dpi etc, its just not needed for this.
> 
> I don't understand this proposal at all. Can you show a concrete example 
> of how you see this working?

Please see the <img> example above.

...
> > Image cropping and centering is something best left to JS algorithms.  
> > Fluid cropping and centering may need an algorithm that takes into 
> > account particular areas of interest and focus within an image, and user 
> > choices which would be better handled within the webpage and not at the 
> > browser level.  A web gallery may allow visitors to choose to scale 
> > versus crop images and to pan cropped image.
> 
> Actually panning and so on would presumably best be done using <canvas>. I 
> don't think we need to be providing a declarative way to do this.

This does seem to conflict with the srcset proposals 'artistic' choice of image crops. 

Btw <canvas> is not necessary for panning and cropping, the image can be positioned through styling and this can be modified by JS based on buttons or mouse movement etc.



cheers
Fred