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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
