[webkit-dev] Accept- & Content-Resolution headers proposal
robburns1 at mac.com
Thu Jun 7 13:26:01 PDT 2007
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
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
I think you should take another look at it. Your objections don't
really address the proposal.
More information about the webkit-dev