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: default.72dpi.css default.144dpi.css default.288dpi.css default.2400dpi.cssIn this instance, the 144 DPI stylesheet would be returned, because it is the next size up, with a header:
Content-Resolution: 144 dpiThe 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)
Furthermore:• 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
