On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote:
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 don't think it's a good idea to handle this at the HTTP level,
because that requires server-side changes and approaches are possible
which handle things purely on the client side.
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
This is a bad idea for a number of reasons:
1) CSS already has media queries to select from multiple stylesheets
in HTML/XML, or to select from multiple blocks in a single stylesheet.
2) DPI is not really the relevant factor to make the decision, what's
important is the UI scale factor. If I'm running at 144 DPI but at 1x
scale, I want the same images as at 72 dpi 1x scale.
3) Passing the resolution to the server forces the selection logic to
be on the server side, not the client. But that's not really sensible
- if the server has multiple resolution versions of a resource, such
as an image, it should advertise them to the client and let the client
choose. For example, at 1.5 UI scale factor, if the server has 3x and
2x images available the client could reasonably choose 2x (the next
scale up) or 3x (since it is an integer multiple of the scale factor).
The server has the following to choose from:
default.72dpi.css
default.144dpi.css
default.288dpi.css
default.2400dpi.css
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)
This doesn't make sense with the way clients actually work. What you
care about with images embedded in web content is the relative scale
of CSS pixels relative to device pixels, which does not have any
necessary direct relation to the physical DPI. You don't actually want
to serve different images to different DPI screens if they are both
running at the same scale factor.
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.
I think the whole design of it is wrong. It's based on DPI instead of
scale factor, it pushes the decision to the server when it should be
made on the client side, and it handles things at the HTTP level that
should be (and indeed are) handled by CSS media queries.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
