Re: [webkit-dev] Accept- & Content-Resolution headers proposal

Hi,

> Accept-Resolution: 116.66 dpi
> ...
> 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)

Why force a "next size up" if most UAs prefer a dpi which is "close  
enough"?

All the other Accept-XXX headers (except Accept-Ranges) uses a  
wildcard if other values are accepted, e.g. (RFC 2616)
   section 14.2:  Accept-Charset: iso-8859-5, *
   section 14.3:  Accept-Encoding: gzip, *
   section 14.4:  Accept-Language: da, en, *

All 3 supports adding a "quality value which represents the user's  
preference for that charset/...".  Could this be used to allow the UA  
to tell the server if it wants a "higher up" or "closest"?


I assume this would be used too when printing a web-page, so the  
printed output can use high-resultion images.  (I've implemented a  
page which uses high-resolution GIFs for icons, and it is a pita to  
maintain).

But how are the browser going to know which files it should re- 
request when printing the page? All, or only those with a "Content- 
Resolution"?

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

As a web-server implementor, I would prefer keeping the standard as  
simple as possible (i.e. KISS), especially with options almost no  
browsers are going to use. Your scheme for selecting the proper css  
file works spendid with dpcm values converted to dpi.  If a webserver  
wants to support .css files named using dpcm, e.g. "default. 
30dpcm.css", that's fine, but don't make the protocol more complex.  
Continuing with this, I would remove "dpi" from the header value, and  
simply define both headers value to be dpi.

----
    - Peter Speck

Received on Thursday, 7 June 2007 15:30:01 UTC