[whatwg] Resolutions meta tag proposal

[Marques Johansson]

On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan <aral at aralbalkan.com> wrote:
> ...
> http://wiki.whatwg.org/wiki/MetaExtensions#Proposals

"In this case, the developer would provide 2x, 4x, and 8x versions of all
images. So, in the running example, she would make flower.jpg, flower at 2x.jpg,
flower at 4x.jpg, and"

And what if the image was named "images/flower" (using the accept header to
send a jpg vs png vs gif) instead of "flower.jpg".  The browser would need
to have rules about how to rewrite the name of the file.  I think "@" in the
filename would break the many Dos 6.22 based web servers ;-).

I don't think a single element with a single attribute can handle this
problem.

What about an HTTP header like:

Accept: image/*;ppiratio=2

This would allow the server to send the correct images for that client or
return a 307 to the rewritten filename as the server deems fit.  A new
Accept property doesn't seem to require changing any specs.   I'ld like to
think that image/*;q=x could be used in some way for this.

On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan <aral at aralbalkan.com> wrote:
> I just submitted a proposal for a new meta tag to flag that
> high-resolution images are available and should be loaded in place of
> low-resolution ones for users with high-PPI displays (like the new
> iPhone 4's Retina display).
>
> Please see:
>
> http://wiki.whatwg.org/wiki/MetaExtensions#Proposals
>
> (Currently, although you can use the min-device-pixel-ratio CSS Media
> Query to achieve this for background images, no such mechanism exists
> for images displayed via the <img> tag short of setting a flag in CSS
> and using image substitution via JavaScript. This new meta tag
> proposes a JavaScript-free and easy-to-author mechanism to handle the
> above use case.)
>
> I look forward to hearing your thoughts :)
>
> All the best,
> Aral
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/e8164bcf/attachment-0002.htm>