I guess that the debate is symptomatic for vendor-led extensions that get adopted by (lazy) developers quickly and forced on the rest of the world as a de facto standard. More responsible developers then have to spend years ironing out the kinks or outright errors and adding workarounds to maintain compatibility for the millions of sites that will never get updated.
Like the viewport tag, it’s quite clear to me that markup is entirely the wrong place for this aspect of content negotiation which is essentially one of infrastructure.
First of all we should take a deep breath and realise that this is only a temporary problem. Very high pixel density screens are becoming the norm on mobile phones and tablets due to the commodification of the technology. As these are precisely the devices that are driving the debate, in a couple of years at most there won’t be a need to differentiate between high-resolution and ultra-high-resolution mobile devices.
The browser should be able to request the appropriate image depending on context. The best solution for this would be via an http-header similar to “accept-gzip”, say “accept-hires” would work filters in the http-server such as mod_pagespeed, which is in fact already doing much of the necessary work with the added goody of transcoding to Webp for browsers that support it (higher quality, lower bandwith = win win). Negotiation at the server level also allows for bandwidth to be considered – the browser can simply turn off the header if appropriate.
Designers and web developers would be able to ignore the problem by simply supplying a single file at the largest size. Deployment at the server level becomes even easier as more and more sites move onto content delivery networks that offer mod_pagespeed or similar.
A container format, similar to the icon format, could be the icing on the cake, but with all the problems of introducing a new image format entails: not only do browsers and servers have to be updated but image editing software as well.
I do like the <picture> tag because it is orthogonal to the <video> tag and supports cropping via media queries in CSS.
Charlie
I guess that the debate is symptomatic for vendor-led extensions that get adopted by (lazy) developers quickly and forced on the rest of the world as a de facto standard. More responsible developers then have to spend years ironing out the kinks or outright errors and adding workarounds to maintain compatibility for the millions of sites that will never get updated.
Like the viewport tag, it’s quite clear to me that markup is entirely the wrong place for this aspect of content negotiation which is essentially one of infrastructure.
First of all we should take a deep breath and realise that this is only a temporary problem. Very high pixel density screens are becoming the norm on mobile phones and tablets due to the commodification of the technology. As these are precisely the devices that are driving the debate, in a couple of years at most there won’t be a need to differentiate between high-resolution and ultra-high-resolution mobile devices.
The browser should be able to request the appropriate image depending on context. The best solution for this would be via an http-header similar to “accept-gzip”, say “accept-hires” would work filters in the http-server such as mod_pagespeed, which is in fact already doing much of the necessary work with the added goody of transcoding to Webp for browsers that support it (higher quality, lower bandwith = win win). Negotiation at the server level also allows for bandwidth to be considered – the browser can simply turn off the header if appropriate.
Designers and web developers would be able to ignore the problem by simply supplying a single file at the largest size. Deployment at the server level becomes even easier as more and more sites move onto content delivery networks that offer mod_pagespeed or similar.
A container format, similar to the icon format, could be the icing on the cake, but with all the problems of introducing a new image format entails: not only do browsers and servers have to be updated but image editing software as well.
I do like the <picture> tag because it is orthogonal to the <video> tag and supports cropping via media queries in CSS.