W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Accept- & Content-Resolution headers proposal

From: Nicholas Shanks <contact@nickshanks.com>
Date: Thu, 7 Jun 2007 14:27:20 +0100
To: ietf-http-wg@w3.org
Message-Id: <BC8CD09E-5FD4-4B92-B55F-0358C4714E88@nickshanks.com>
Cc: WebKit Development <webkit-dev@lists.webkit.org>
It has been mentioned on the Safari WebKit development mailing list  
that a HTTP header which specified a document's target resolution  
would be useful to allow clients to negotiate for high-res or low-res  
artwork and CSS referring to such (background-image, and the like),  
depending on their screen pixels, printer resolution, etc.
I would like to propose this to the Working Group.
My ideas are as follows:

The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi

The server has the following to choose from:


In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:

Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page zoom  
of 200% would request 233.33 dpi)


 Images served with a Content-Resolution header could have their  
resolution trusted (most web browsers today display one pixel on  
screen per pixel in the bitmap, and ignore the image's internal  
resolution parameter, if one exists). If they don't match, probably  
best to use the image's internal one. There could also be a special  
"Content-Resolution: auto-adjust" header meaning that the server  
doesn't know the resolution at content-negotiation time, but wants  
the client to scale it according to the image's internal value  
anyway, and not do a pixel-to-pixel mapping.

 A "dpcm" (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.

What do people think? I've only spent an hour or so pondering this,  
so it won't be bulletproof yet.

- Nicholas.

Received on Thursday, 7 June 2007 13:27:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC