Macej,
I think you misunderstand the proposal. It does take scale factor
into account. It also is meant to handle other cases (not just CSS).
I do think you're right about the server advertising the
possibilities, but that would probably complicate things a lot. In
any case its better than simply getting a one-size-fits all bitmap
image.
Take care,
Rob
On Jun 7, 2007, at 2:58 PM, Maciej Stachowiak wrote:
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.
This is meant for a more flexible approach that also works outside CSS.
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.
Don't you mean 0.5x 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).
This is a valid issue, but perhaps it could be addressed in the
proposal. Its better than the alternative of no non-css approach.
However, keep in mind that In a purse CSS environment, the author
doesn't take into consideration the processing needs off the client
anymore than the server does. The CSS (written by the author) will
determine which pixel dimension image the client gets).
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.
I think you're saying the same thing in different language. Both Mac
OS X and CSS were designed with resolution independence in mind. The
distinction over devise pixels and CSS pixels merely muddies the
issue. An image that's specified to be 4 inches square on a 96dpi
display at 50% zoom is 192 pixels square (however you want to say
it). Getting that pixel dimension image delivered form the server is
what we're looking for (or perhaps a different pixel dimension if the
client expects a resizing or immediate printing).
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.
I think you should take another look at it. Your objections don't
really address the proposal.
Take care,
Rob
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev