4 ms·

Think I agree. I feel like we would expect to see a resolution is either normal or double in dimensions. But currently with media attributes we are able to set

by Kequc 13y ago

Think I agree. I feel like we would expect to see a resolution is either normal or double in dimensions. But currently with media attributes we are able to set the image property in CSS by itself and it gives us much more control. Particularly useful in instances where our images aren't exactly normal or double in dimensions but are resized. Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?

pornel 13y ago
Media query syntax has been proposed: <picture><source media="min-resolution: 2ppx"></picture> but mere query doesn't affect intrinsic size of the image, so you'd also need to specify exact dimensions in the markup or something like: <picture> <source media="min-resolution: 2dppx" style="image-resolution: 2dppx"> </picture> which is rather verbose and error-prone compared to srcset. > Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x? I don't think so (meaning of "1x" gradually changed from 72dpi to 100-130dpi, so I expect "2x" similarly gradually increase) and I proposed that new image embedding methods default to @2x, but that idea hasn't gained support from CSS/HTML WGs.
- Kequc 13y ago
  It could assume you are defining image dimensions in the stylesheet the way that normal image tags do. Or it can default to the image scaled down to 2ppx as defined in the media query. Your example looks similar to current audio tags. <audio controls> <source src="horse.ogg" type="audio/ogg"> <source src="horse.mp3" type="audio/mpeg"> Your browser does not support the audio element. </audio>
hcarvalhoalves 13y ago
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.

by Kequc 13y ago

pornel 13y ago

Media query syntax has been proposed: <picture><source media="min-resolution: 2ppx"></picture> but mere query doesn't affect intrinsic size of the image, so you'd also need to specify exact dimensions in the markup or something like: <picture> <source media="min-resolution: 2dppx" style="image-resolution: 2dppx"> </picture> which is rather verbose and error-prone compared to srcset. > Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x? I don't think so (meaning of "1x" gradually changed from 72dpi to 100-130dpi, so I expect "2x" similarly gradually increase) and I proposed that new image embedding methods default to @2x, but that idea hasn't gained support from CSS/HTML WGs.

Kequc 13y ago
It could assume you are defining image dimensions in the stylesheet the way that normal image tags do. Or it can default to the image scaled down to 2ppx as defined in the media query. Your example looks similar to current audio tags. <audio controls> <source src="horse.ogg" type="audio/ogg"> <source src="horse.mp3" type="audio/mpeg"> Your browser does not support the audio element. </audio>

hcarvalhoalves 13y ago

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.