4 ms·

The elephant in the room is, what "normal" and "double" even mean? It could be negotiating content based on something actually meaningful, like viewport size, D

The elephant in the room is, what "normal" and "double" even mean? It could be negotiating content based on something actually meaningful, like viewport size, DPI, even connection speed. This spec is broken as soon as we have to worry about something other than retina displays. You can see they are basically getting this very vendor-specific hack they already had and calling it a standard. That's heresy.

grey-area 13y ago
Exactly. They should be reporting the resolution of each image in pixels, and leave the client to figure out what they want to download based on variables like connection speed, screen PPI, user settings etc. Trying to specify a scale just doesn't make sense, because the UA might be any resolution or multiple resolutions, might degrade for edge connections etc - the UA is best-placed to decide which images it wants, and that should be on the basis of source image resolution in pixels, not some arbitrary scale. Using 2x, 4x, 1280w is tied to the conventions of our current devices, which will change many times in the future, and doesn't provide useful information about the src image itself. Why do this? They've done the same thing with resolution independence on iOS - instead of some sensible system of scaling and caching, we've ended up with a situation where images and icons are saved in several different versions by the developer just to cope with all the different possible resolutions/ratios using this sort of @2x naming scheme, and all based off arbitrary resolutions of screens which are going to change. It's a mess. I think they'd be better with something like this: <picture> <source src="myjpg.jpg" width=100 height=100> <source src="myjpglrg.jpg" width=1000 height=1000> <img src="myjpg.jpg" alt="fallback img tag or text"> </picture> We already have this scheme of source elements for audio and video, and this is the perfect moment to introduce something a bit more sane for images too. There's no need for the specification of arbitrary resolution intents if you give the src sizes. This would also let us transparently handle new file formats with fallback to older ones with type attributes, as with audio and video tags. For example you might start introducing SVG versions of many images, but leave a png source in there for older browsers. The above proposal already displays perfectly fine in older browsers if you use an img tag within the <picture> tags for backwards compatibility, and could easily be dealt with in older IE with workarounds if necessary, though I think the img tag would display fine. CSS can then be used to control the intended display size.
- extra88 13y ago
  Not addressing anything else you raised but width and height are insufficient for making network performance and network budget decisions. Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression.
  - grey-area 13y ago
    Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression. Yes, that's true, though generally pixel size does relate quite well to file size for different versions of a given image on the web, and a picture element could just have sources in order of preference of use (regardless of size), so basically quality order - I think that's what the video element does (though for formats, not sizes)? The browser could choose different images depending on quality/bandwidth/resolution concerns, so it wouldn't always have to use the first. If not a quality attribute or something similar would be easy enough to add. I think the basic idea of the audio and video/source elements is fine, and should be extended to images as it could cover lots of use cases - don't really mind about the details as I'm sure they could be worked out. The best way to get good retina images I've found so far is simply to oversize and compress heavily, which gives surprisingly good results and small files even for large images - I'd love to use something like the new picture element for multiple resolutions so that I could also provide a smaller version for lower bandwidth uses, but frustratingly webkit authors seem to see the picture element as somehow superseded by srcset, even though it doesn't do what a picture element would do, and introduces yet more headaches. I wouldn't consider using srcset for the reasons given above and because I've already experienced this solution in iOS dev, and it was equally broken there.
- chrisoverzero 13y ago
  The UA can do whatever it wants; the information given in srcset is for giving the UA the clues it needs to make the right decision. [0] > From the available options, the user agent then picks the most appropriate image. So if you are zoomed in, the UA can decide that a higher-res image is the most appropriate one. [0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset http://www.whatwg.org/specs/web-apps/current-work/multipage/...
simonw 13y ago
"You can see they are basically getting this very vendor-specific hack they already had and calling it a standard. That's heresy." No, that's HTML5.
- jgraham 13y ago
  It's also a total mischaracterisation of what happened here. This was not a case where someone implemented the feature and we were forced to go with they syntax for compatibility reasons. There was extensive discussion about the use cases, best approach, and so on. It turns out to be a much harder problem than you might have thought. For just one example of a subtlety, browser vendors find <picture><source> type syntaxes harder because they can't be processed atomically; for example: <picture> <source src="foo"> <script>document.getElementsByTagname("source")[0].src = "bar"</script> [...] is complexity that simply can't happen with srcset. Similarly one needs to consider the behaviour of preloaders in extant UAs; if existing browsers will start to download all the images that will create a much worse user experience in the short term. I don't remember what all the considerations were here, but this is a much harder problem than many people give credit for, and certainly isn't a case where a single vendor controlled the whole process.
  - grey-area 13y ago
    With respect, making life easier for browser makers is the worst possible reason to choose a feature which will be used by millions of documents (or not, in the case of srcset) over another with a better syntax. I'm not even clear why onload on an img tag would not also invalidate your img example above, but that doesn't even matter. Hacks for performance may be fine in browser or server code in some circumstances, but are absolutely not fine in a public document format like HTML. Is the picture element containing source elements (like video and audio) still under consideration, or is srcset supposed to replace it somehow?
chrisoverzero 13y ago
The multipliers refer to the ratio of device pixels to software pixels ("CSS pixels"). Content can be negotiated via viewport size, it's just that Webkit doesn't support that part yet. [0] The pixel ratio is better information than DPI, and connection speed is a difficult and unreliable metric. [0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset http://www.whatwg.org/specs/web-apps/current-work/multipage/...

grey-area 13y ago

Exactly. They should be reporting the resolution of each image in pixels, and leave the client to figure out what they want to download based on variables like connection speed, screen PPI, user settings etc. Trying to specify a scale just doesn't make sense, because the UA might be any resolution or multiple resolutions, might degrade for edge connections etc - the UA is best-placed to decide which images it wants, and that should be on the basis of source image resolution in pixels, not some arbitrary scale. Using 2x, 4x, 1280w is tied to the conventions of our current devices, which will change many times in the future, and doesn't provide useful information about the src image itself. Why do this? They've done the same thing with resolution independence on iOS - instead of some sensible system of scaling and caching, we've ended up with a situation where images and icons are saved in several different versions by the developer just to cope with all the different possible resolutions/ratios using this sort of @2x naming scheme, and all based off arbitrary resolutions of screens which are going to change. It's a mess. I think they'd be better with something like this: <picture> <source src="myjpg.jpg" width=100 height=100> <source src="myjpglrg.jpg" width=1000 height=1000> <img src="myjpg.jpg" alt="fallback img tag or text"> </picture> We already have this scheme of source elements for audio and video, and this is the perfect moment to introduce something a bit more sane for images too. There's no need for the specification of arbitrary resolution intents if you give the src sizes. This would also let us transparently handle new file formats with fallback to older ones with type attributes, as with audio and video tags. For example you might start introducing SVG versions of many images, but leave a png source in there for older browsers. The above proposal already displays perfectly fine in older browsers if you use an img tag within the <picture> tags for backwards compatibility, and could easily be dealt with in older IE with workarounds if necessary, though I think the img tag would display fine. CSS can then be used to control the intended display size.

extra88 13y ago
Not addressing anything else you raised but width and height are insufficient for making network performance and network budget decisions. Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression.
- grey-area 13y ago
  Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression. Yes, that's true, though generally pixel size does relate quite well to file size for different versions of a given image on the web, and a picture element could just have sources in order of preference of use (regardless of size), so basically quality order - I think that's what the video element does (though for formats, not sizes)? The browser could choose different images depending on quality/bandwidth/resolution concerns, so it wouldn't always have to use the first. If not a quality attribute or something similar would be easy enough to add. I think the basic idea of the audio and video/source elements is fine, and should be extended to images as it could cover lots of use cases - don't really mind about the details as I'm sure they could be worked out. The best way to get good retina images I've found so far is simply to oversize and compress heavily, which gives surprisingly good results and small files even for large images - I'd love to use something like the new picture element for multiple resolutions so that I could also provide a smaller version for lower bandwidth uses, but frustratingly webkit authors seem to see the picture element as somehow superseded by srcset, even though it doesn't do what a picture element would do, and introduces yet more headaches. I wouldn't consider using srcset for the reasons given above and because I've already experienced this solution in iOS dev, and it was equally broken there.
chrisoverzero 13y ago
The UA can do whatever it wants; the information given in srcset is for giving the UA the clues it needs to make the right decision. [0] > From the available options, the user agent then picks the most appropriate image. So if you are zoomed in, the UA can decide that a higher-res image is the most appropriate one. [0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset http://www.whatwg.org/specs/web-apps/current-work/multipage/...

simonw 13y ago

"You can see they are basically getting this very vendor-specific hack they already had and calling it a standard. That's heresy." No, that's HTML5.

jgraham 13y ago
It's also a total mischaracterisation of what happened here. This was not a case where someone implemented the feature and we were forced to go with they syntax for compatibility reasons. There was extensive discussion about the use cases, best approach, and so on. It turns out to be a much harder problem than you might have thought. For just one example of a subtlety, browser vendors find <picture><source> type syntaxes harder because they can't be processed atomically; for example: <picture> <source src="foo"> <script>document.getElementsByTagname("source")[0].src = "bar"</script> [...] is complexity that simply can't happen with srcset. Similarly one needs to consider the behaviour of preloaders in extant UAs; if existing browsers will start to download all the images that will create a much worse user experience in the short term. I don't remember what all the considerations were here, but this is a much harder problem than many people give credit for, and certainly isn't a case where a single vendor controlled the whole process.
- grey-area 13y ago
  With respect, making life easier for browser makers is the worst possible reason to choose a feature which will be used by millions of documents (or not, in the case of srcset) over another with a better syntax. I'm not even clear why onload on an img tag would not also invalidate your img example above, but that doesn't even matter. Hacks for performance may be fine in browser or server code in some circumstances, but are absolutely not fine in a public document format like HTML. Is the picture element containing source elements (like video and audio) still under consideration, or is srcset supposed to replace it somehow?

chrisoverzero 13y ago

The multipliers refer to the ratio of device pixels to software pixels ("CSS pixels"). Content can be negotiated via viewport size, it's just that Webkit doesn't support that part yet. [0] The pixel ratio is better information than DPI, and connection speed is a difficult and unreliable metric. [0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset http://www.whatwg.org/specs/web-apps/current-work/multipage/...