[whatwg] Defaulting new image solution to 192dpi
My suggestion is that the srcset (or picture) should assume that images are 2x scale by default. My reasoning behind is: - we have img for easy embedding of 1x images today, but we don't have 2x img for the future. Having to specify width/height in img all the time is annoying. - highdpi displays will become dominant at some point, it's only a matter of time (they pretty much are already in high-end smartphones, and are going to appear in laptops next). Bandwidth is also going to be less of a concern, so it'll be rational and desirable to serve images for the 2x resolution only (and just rely on 96dpi displays scaling them down). Necessity to specify 2x scaling all the time will become a bad default and a historical quirk (like the DOCTYPE), and a source of annoyance where accidentally omitted 2x syntax makes images large and pixelated. So to future-proof the solution I think: img src=1x.jpg srcset=2x.jpg should be equivalent to: img src=1x.jpg srcset=2x.jpg 2x and I expect that it'll eventually be commonly used this way: img srcset=2x.jpg when people stop caring about bandwidth overhead for low-end displays. The srcset still allows 1x scale to be specified, so this change doesn't take any functionality away. -- regards, Kornel Lesiński
Re: [whatwg] Defaulting new image solution to 192dpi
On 2012-05-17 13:30, Kornel Lesiński wrote: My suggestion is that the srcset (or picture) should assume that images are 2x scale by default. My reasoning behind is: - we have img for easy embedding of 1x images today, but we don't have 2x img for the future. Having to specify width/height in img all the time is annoying. - highdpi displays will become dominant at some point, it's only a matter of time (they pretty much are already in high-end smartphones, and are going to appear in laptops next). Bandwidth is also going to be less of a concern, so it'll be rational and desirable to serve images for the 2x resolution only (and just rely on 96dpi displays scaling them down). Necessity to specify 2x scaling all the time will become a bad default and a historical quirk (like the DOCTYPE), and a source of annoyance where accidentally omitted 2x syntax makes images large and pixelated. So to future-proof the solution I think: img src=1x.jpg srcset=2x.jpg should be equivalent to: img src=1x.jpg srcset=2x.jpg 2x ... As far as I can tell, making descriptors optional breaks the syntax (it allows comma both in the URI and as a separator between image candidates). (Please read this as argument for making the syntax less brittle) Best regards, Julian
Re: [whatwg] Defaulting new image solution to 192dpi
On 17 May 2012 13:05, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 12:52:47 +0100, Andy Davies dajdav...@gmail.com wrote: My suggestion is that the srcset (or picture) should assume that images are 2x scale by default. Doesn't this makes the assumption that pixel density is the most likely reason for needing the alternative image rather than viewport / image dimensions? Those two cases are orthogonal — one doesn't exclude the other, and I'm not claiming that it solves the art-directed case. srcset can be used to offer alternatives for higher or lower DPI, and/or larger or smaller viewports so I'm still not convinced that an assumption that somehow it should assume that the srcset images are 2x scale by default really helps. Much of the usage I've seen for responsive images so far has concentrated on providing images that change with viewport size rather than DPI. Cheers Andy
Re: [whatwg] Defaulting new image solution to 192dpi
On 17 May 2012 14:19, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 13:47:12 +0100, Andy Davies dajdav...@gmail.com wrote: srcset can be used to offer alternatives for higher or lower DPI, and/or larger or smaller viewports so I'm still not convinced that an assumption that somehow it should assume that the srcset images are 2x scale by default really helps. Much of the usage I've seen for responsive images so far has concentrated on providing images that change with viewport size rather than DPI. Let me reiterate: it doesn't matter. Those are *separate* issues. Responsive image is a bad term as it conflates two distinct problems (screen density adaptation and physical screen size adaptation) into one. It's not either-or choice. Both have valid use-cases. Support for high DPI displays is an absolute necessity. Don't look at current or past. Think how web development is going to look like in 5, 10 or 20 years. There will be no low-res displays in the future. Everybody is going to have Retina displays and everybody will hate that img or picture inserts crappy pixelated images. Try browsing the web on the new iPad today. That's how every display is going to look like in 10, maybe 20 years. Then DPI negotiation will not be an option, it'll be absolute requirement for *every* *single* image. HTML5 is designed for the next 50-100 years. The last line is exactly why baking in an assumption on the defaults isn't the right way to go. I don't disagree that higher DPI resolutions will be come the norm but then what are we going to do about lower DPI devices, serve them a higher DPI than needed image and let them work it out rather than serve them appropriate images? The Zombie Apocalypse is coming there will be plenty of lower DPI screens around for a long time... Cheers Andy
Re: [whatwg] Defaulting new image solution to 192dpi
On Thu, 17 May 2012 14:42:19 +0100, Andy Davies dajdav...@gmail.com wrote: Try browsing the web on the new iPad today. That's how every display is going to look like in 10, maybe 20 years. Then DPI negotiation will not be an option, it'll be absolute requirement for *every* *single* image. HTML5 is designed for the next 50-100 years. The last line is exactly why baking in an assumption on the defaults isn't the right way to go. I know, somebody will quote me on 192dpi is enough for everybody, but we have 1x scaling assumption baked in already, so I'm suggesting changing existing bad assumption to a less bad assumption. I don't disagree that higher DPI resolutions will be come the norm but then what are we going to do about lower DPI devices, serve them a higher DPI than needed image and let them work it out rather than serve them appropriate images? Yes. You do the same for 256-color and monochrome displays today, because potential bandwidth savings are small and popularity/quality of those screens is not significant enough to care. The Zombie Apocalypse is coming there will be plenty of lower DPI screens around for a long time... Bandwidth will increase to the point that serving highdpi image to everybody won't be an issue. Would you care about 100KB image vs 200KB image on 1Gbit connection? Google Fiber project is experimenting with such speeds already. The answer is no: it takes only 0.8ms more, so even with *100* such images on the page the delay is literally comparable to blink of an eye (http://www.wolframalpha.com/input/?i=100KB+%2F+1Gbit+*+100) The scaling factor won't increase forever, it's only going to be increasing until it matches capabilities of human vision. Depending on screen and viewing distance 2x is already claimed to be perfect (Retina display). -- regards, Kornel Lesiński
Re: [whatwg] Defaulting new image solution to 192dpi
On Thu, May 17, 2012 at 4:30 AM, Kornel Lesiński kor...@geekhood.net wrote: My suggestion is that the srcset (or picture) should assume that images are 2x scale by default. My reasoning behind is: - we have img for easy embedding of 1x images today, but we don't have 2x img for the future. Having to specify width/height in img all the time is annoying. - highdpi displays will become dominant at some point, it's only a matter of time (they pretty much are already in high-end smartphones, and are going to appear in laptops next). Bandwidth is also going to be less of a concern, so it'll be rational and desirable to serve images for the 2x resolution only (and just rely on 96dpi displays scaling them down). I think this will be a confusing change that will hurt more than it helps. URLs in @srcset should act exactly like URLs in @src, except where modified by the descriptors. Necessity to specify 2x scaling all the time will become a bad default and a historical quirk (like the DOCTYPE), and a source of annoyance where accidentally omitted 2x syntax makes images large and pixelated. I think that 2x only looks like a good default now. I would bet that in less than 10 years 3x or higher will look like a good default. I'd rather not bake in a confusing change that doesn't actually future-proof anything. ~TJ
Re: [whatwg] Defaulting new image solution to 192dpi
On Thu, 17 May 2012 16:05:13 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: Necessity to specify 2x scaling all the time will become a bad default and a historical quirk (like the DOCTYPE), and a source of annoyance where accidentally omitted 2x syntax makes images large and pixelated. I think that 2x only looks like a good default now. I would bet that in less than 10 years 3x or higher will look like a good default. So why is 1x the default when it's obvious that it is not going to be a good default? If density is still absent, set it to 1.0. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#image-candidate-string Note that the scale multiplier can be omitted already when only the size is specified: img srcset=img 500w This is currently a legal syntax for a 1x image, and this is going to be an awful mistake regardless whether we'll have 2x or 3x displays in the future. I'd rather not bake in a confusing change that doesn't actually future-proof anything. I think it's a safe bet that 3x won't ever be a good default. Authors will need to translate between CSS and image pixel sizes, and it's much easier to multiply and divide by 2 than 3. Keep in mind that scaling factor is not tied too much to actual display DPI/perceived pixel size. When new denser displays come along, we won't jump from 2x to 3x, rather the 2x will change its meaning. This is exactly what happened with pixel size at 1x — it has shrunk over the years from 72dpi (SVGA 14) to 108dpi (iMac 27) and 130dpi on laptops. Assuming same viewing distances, that's a hefty 1.5-1.8x increase in resolution! When resolution of current desktops doubles we'll start at around 200dpi, and the pixel size will likely continue to shrink gradually over time as displays get less-than-full-multiplier increases in density. If such 1.5-1.8 increase happens again, the meaning of 2x will end up being in the 300-360dpi range for desktop viewing distances. That will be much better than 264dpi on the Retina iPad today (even better considering iPad's smaller viewing distance). Those pixels will be much smaller than average human can see — I think that's perfectly adequate for a default! Further improvements over this would have diminishing results — once pixels are indistinguishable it won't make sense to make them more indistinguishable, so there will be very little reason to use 3x, 4x factors. But let's say I'm wrong and 3x will end up being the ultimate scaling factor: - when authors specify the 3x scaling factor explicitly, it'll all work fine regardless of the default. - if the we don't change the default, then failing to specify the 3x scale factor will give very wrong result — a 1x image. - if we change the default to 2x, then failing to specify the 3x scale factor will give less wrong result — a 2x image. Only if we change the default to 3x now, before srcset ships we will avoid the problem entirely. But as I've explained above, it's an inconvenient scaling factor and is likely to overshoot required quality, so 2x is a safer bet. But why oh why should we keep 1x as the default if it's going to be the worst default in any case? -- regards, Kornel Lesiński
Re: [whatwg] Defaulting new image solution to 192dpi
Kornel wrote: Note that the scale multiplier can be omitted already when only the size is specified I'm confused by what you mean by scale multiplier. The x value describes the pixel density of the device/screen, not the image, right? Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Defaulting new image solution to 192dpi
On Thu, May 17, 2012 at 11:23 AM, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 16:05:13 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: Necessity to specify 2x scaling all the time will become a bad default and a historical quirk (like the DOCTYPE), and a source of annoyance where accidentally omitted 2x syntax makes images large and pixelated. I think that 2x only looks like a good default now. I would bet that in less than 10 years 3x or higher will look like a good default. So why is 1x the default when it's obvious that it is not going to be a good default? Because it's simple (1 image pixel = 1 CSS pixel), and it was the historical default. ~TJ
Re: [whatwg] Defaulting new image solution to 192dpi
On Thu, 17 May 2012 19:33:07 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I think that 2x only looks like a good default now. I would bet that in less than 10 years 3x or higher will look like a good default. So why is 1x the default when it's obvious that it is not going to be a good default? Because it's simple (1 image pixel = 1 CSS pixel), and it was the historical default. But it's going to become completely useless and nobody is going to use it. 2x default at least has a chance of not being useless. -- regards, Kornel Lesiński
Re: [whatwg] Defaulting new image solution to 192dpi
On Thu, 17 May 2012 19:32:51 +0100, Jeremy Keith jer...@adactio.com wrote: Kornel wrote: Note that the scale multiplier can be omitted already when only the size is specified I'm confused by what you mean by scale multiplier. The x value describes the pixel density of the device/screen, not the image, right? I think it only makes sense if it describes the image, so that: img srcset=100x100image-pixels.jpg 2x would display at 50x50px (CSS px). Of course the UA is likely to match 2x with double-density displays, so it acts as both description of the image and a hint media query. If it were purely a media query unrelated to the image, then this: img srcset=100x100image-pixels.jpg 2x, 50x50image-pixels.jpg 1x would only select between pixelated large image and pixelated small image, never making use of a high DPI display. The goal is to avoid having to specify explicit img width/height. Not only it's tedious and annoying, it also makes it impossible to adapt images to viewport and screen density at the same time: img srcset= phone-retina-640imgpx.jpg 2x max-width:320px, phone-regular-320imgpx.jpg 1x max-width:320px, desktop-1000imgpx.jpg 2x, desktop-500imgpx.jpg 1x In the case above I'd want to have phone* images on =320px viewport, matching display density, and desktop* images on larger viewports, taking full advantage of display density as well (i.e. desktop-1000imgpx.jpg 2x displayed at 500px). There is no value of img width= height= that can work for that case without ruining the adaptation img width=500 would work for desktop, but ruin phone versions. So the only way to use srcset in that case would require additional media queries that react to same breakpoints as srcset and set explicit pixel sizes of this image for each breakpoint. Awful. So for me the only logical conclusion is that images with 2x descriptor must have their intrinsic size halved (2 img pixels to 1 css pixel). That's what iOS does when you use @2x images in Cocoa. -- regards, Kornel Lesiński
Re: [whatwg] Defaulting new image solution to 192dpi
On Thu, May 17, 2012 at 11:32 AM, Jeremy Keith jer...@adactio.com wrote: Kornel wrote: Note that the scale multiplier can be omitted already when only the size is specified I'm confused by what you mean by scale multiplier. The x value describes the pixel density of the device/screen, not the image, right? You can think of it either way in this case. Devices with a pixel density less than the Nx descriptor of an image won't download that image if they have a choice (unless you're zooming or something, where the effective pixel density is higher). However, the Nx descriptor does have an effect on the image, by adjusting the intrinsic size of the image. If the image is 600 pixels (image pixels) wide and sent with a 2x descriptor, its intrinsic size will be 300px (CSS px). You'll only notice this if you're using auto-sizing, though. ~TJ
Re: [whatwg] Defaulting new image solution to 192dpi
On May 17, 2012, at 12:20 PM, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 19:32:51 +0100, Jeremy Keith jer...@adactio.com wrote: Kornel wrote: Note that the scale multiplier can be omitted already when only the size is specified I'm confused by what you mean by scale multiplier. The x value describes the pixel density of the device/screen, not the image, right? I think it only makes sense if it describes the image, so that: img srcset=100x100image-pixels.jpg 2x would display at 50x50px (CSS px). That is indeed how it works. Cheers, Maciej
