[webkit-dev] Accept- & Content-Resolution headers proposal

[Rob Burns]

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