3 ms·

Not addressing anything else you raised but width and height are insufficient for making network performance and network budget decisions. Image size in pixels

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

by extra88 13y ago

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.