[webkit-dev] Accept- & Content-Resolution headers proposal
speck at vitality.dk
Thu Jun 7 08:28:54 PDT 2007
> 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
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
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-
> • 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
More information about the webkit-dev