[whatwg] Resolutions meta tag proposal

[Roger Hågensen]

On 2010-07-04 14:34, Marques Johansson wrote:
> Another way about handling this PPI ratio business would be with HTTP 
> 300 multiple choice. 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1
>
> This may not be the best answer for every image on a page, but the 
> first HTML page in a server controlled session could store the PPI 
> ratio setting based on the page the UA chooses and then modify the 
> HTML or content-negotiation setting.  A problem with this is that the 
> browsers wouldn't be likely to render a page correctly unless they 
> were modified for this image request yields 300 behavior.
>
> I still like something like this for client content negotiation:
>
> GET /image/dog HTTP/1.1
> Accept: image/*; ppiratio=2
> ...
> HTTP/1.1 200 OK
> Content-type: image/jpeg
> ... dog at 2x.jpg
>
> Apache rewrite rules could even handle this by detecting ppiratio in 
> the Accept header and then looking for a matching images/ratio/2/dog 
> file.  If it didn't exist the rewrite would fail resulting in the 
> server responding with images/dog which is suitable if not optimal.
>
> This has me thinking "Accept: image/*; x=400; y=300" could be attached 
> with any image request based on clients intent for the image.  (The 
> HTML said 'width=400 height=300' so I don't need anything better.) 
>  The server can ignore this or return something better suited than the 
> 1200x1200 image that it would otherwise return.
>
> I still don't have a handle on this retinal / ppi stuff so "ppiratio" 
> may be the wording.
> I also like "Accept: video/*; kbps=500" for a similar purpose.
>

Again this is negotiation related, and although I'm able to do fancy 
apache stuff on my site I'd rather not have to.

This however takes advantage of CSS 
http://www.alistapart.com/articles/hiresprinting/

Not exactly ideal, but I think it's the better approach, it just need to 
be refined and standardized some way.

But here's an idea I have that would fit into HTML5.

Examples:
1. <img src="img/test.png" width="512" height="256" 
dpi="96;;300;image/test300.png"> work better?
(96 dpi is current thus empty ;; while 300 dpi is alternative hence 
specified.
2. <img src="img/test.png" width="512" height="256" dpi="300"> woould 
also be valid, indicating that the image is 300 dpi and no alternatives.
3. <img src="img/test.png" width="512" height="256" 
dpi="300;image/test300.png"> same as example 1, 96 dpi default assumed.
4. <img src="img/test.png" width="512" height="256" 
dpi="*;image/test.svg"> 96 dpi default assumed, the * indicate any DPI 
and in this case it's a vector format.
If dpi="" or is not specified, then the image should be assumed to be 
96dpi, unless the image format has it's own dpi info (JPG support this, 
but does PNG?) that is.

This would make printouts look better, and allows the author to specify 
displayed size (width and height being logical pixels for non-96 dpi 
images obviously)
High DPI displays would make the browser get the high dpi image instead 
of the default.

The only parts of a site that has issues currently is fixed pixel 
graphics (and fixed pixel based layout as well I guess),
it is only pixel based (bitmapped) images that has issues with scaling,
embed video already tend to offer multiple resolutions.

So a dpi param for img might just be a nice way to fix the issue.
The CSS folks might have to add some support for this too, as well as 
scripting support.

This is just something I came up with right now, but it's at least 
simple in use which is the important thing I guess.

-- 
Roger "Rescator" Hågensen.
Freelancer - http://EmSai.net/