Re: [whatwg] Features for responsive Web design
On Sep 5, 2012, at 12:07 AM, Fred Andrews freda...@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
Re: [whatwg] Features for responsive Web design
From: m...@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
Re: [whatwg] Features for responsive Web design
Fred Andrews writes: From: m...@apple.com 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 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! And how big is 10em? 1em is dependent on the font-size of the parent element of the img, which may be set by an external style-sheet. The browser can immediately determine the image to use and load it in this particular case. You see how easy it would be for authors to get this wrong, even if they knew they had to put image sizes in-line in order to have good performance and tried to do that. That you, the promoter of the feature, can't even get it right suggests that it would also be hard for authors to do so. Cheers Smylers -- New series of TV puzzle show 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect
Re: [whatwg] Features for responsive Web design
From: smyl...@stripey.com ... 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 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! And how big is 10em? 1em is dependent on the font-size of the parent element of the img, which may be set by an external style-sheet. Good point, thanks. But I don't think this weakens any of the technical points. Having the image sizes declared inline can only help speed the layout computation and allows the browser to use higher resolution images when needed. The browser can immediately determine the image to use and load it in this particular case. You see how easy it would be for authors to get this wrong, even if they knew they had to put image sizes in-line in order to have good performance and tried to do that. That you, the promoter of the feature, can't even get it right suggests that it would also be hard for authors to do so. If authors can get the URL right then they can get the sizes right. Web browser developer tools could warn if a mismatch is found - which is not something that could be done to correct incorrect media queries. There is likely a better syntax, and there have been lots of ideas proposed. John Mellor proposed the syntax: img srcset=320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x which has less values and thus less opportunity for user error. Would this help? If you have a better proposal to address the issue then please put it forward? Note that media queries can not solve this problem because the image layout size depends on styling, but media queries should be usable with any solution. cheers Fred
