Re: [whatwg] Features for responsive Web design

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

Yes, the load time is important, and if the images is chosen based only on media queries than it can be loaded immediately.  However the loaded images may not be an appropriate resolution - too small with not enough detail or too larger slowing page load.
 
> > 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.

Actually, the image width is '10em' in this example, without having to load any style sheets!  The browser can immediately determine the image to use and load it in this particular case.

I understand your point though.  The layout size of the <img> element can even change after loading all resources as the user zooms or interacts with the content.   Currently there is only one image choice, and it may be too large which would delay loading or too small and lack detail.

The latency caused by style sheet loading is something accepted long ago.  Pages that need the faster load times, such as landing pages, are going to inline the style, and perhaps even images.  Websites for which visitors are expected to browse many pages would have common style sheets that would be cached and available immediately after the first visit.

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

Consider that it will give the layout engine the image size before the images are loaded, because the sizes are declared inline.  This could significantly reduce layout delays.   Knowing the layout earlier could help make better decisions about image load order.

Further, the layout engine may well be able to load a smaller lower resolution images, reducing load times.

Page load times could be faster than they currently are by firstly loading the lowest resolution images - and it would even be more practical to inline these in data: URLs.   Users may well prefer to have pages load faster with low resolution images and accept the delay waiting to higher resolution images to load.

There do appear to be opportunities to achieve even faster page load times, and a better user experience.  Perhaps you could take another look at the issues and opportunities.

cheers
Fred

Received on Saturday, 8 September 2012 08:59:35 UTC