[whatwg] Resolutions meta tag proposal

[André Luís]

G'day,

since the discussion is more or less trying to find a solution in the
markup realm (which I thoroughly support), I'm gonna focus on Roger's
proposal of @dpi.

I believe the proposal might work. But assuming you might want to
target 3x resolutions on all <img> the size of the document will
increase.

Like Roger said, it's very important to have this working on a several of ways.

1) content negotiation, at the server level.
2) markup, @dpi or other attribute specifying an alt resource for each
resolution ( <img src resolutions="">?)
3) css, media queries are able to do this.. right?
4) javascript, give access to the document's current resolution in
dpi's, under screen.resolution?

Although, on point 2, i still prefer the way I suggested earlier, to
make <img> work like the other media tags: <video> <audio>, with child
<source> elements that could have either a resolution="96" (per
proposal of Roger) attribute or a media query...

Anyway, is it still time to have this conversation? Will additions to
the spec be considered?

Since this Retina (high res screens) business is very new, there isn't
much real-world usage to harvest proof of... but is there a process or
a set of steps a proposal must go through?

--
André Luís
http://id.andr3.net/

On 4 July 2010 21:57, Roger Hågensen <rescator at emsai.net> wrote:
> 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/
>
>