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

[Maciej Stachowiak]

On Jun 7, 2007, at 1:26 PM, Rob Burns wrote:

> 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.

It can be done in the CSS file for CSS backgrounds using media  
queries, this allows things to work without any server-side changes.  
The only case that needs to be addressed better IMO is foreground  
images via <img>. And that should probably be handled at the HTML or  
CSS level, not the HTTP level.

> In any case its better than simply getting a one-size-fits all  
> bitmap image.

The scale factor is the only thing that *actually* matters. The DPI is  
irrelevant. (And as Hyatt pointed out, the actual scaling an image  
gets might depend on the specific context in the page.)

  - Maciej

>
>
> 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