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

[Andre-John Mas]

Surely all of this becomes moot if we specify objects in terms of  
inches, cm or mm, all of which are already supported by css? A  
browser that interprets these 'absolute' units properly should  
already know what DPI the current environment is in, or have access  
to the necessary API to display correctly.

The problem that we have today is that some environments don't tell  
the application the real DPI, so the application is left guessing and  
mis-rendering things on screen.

The other thing that must be taken account is that on a multi-headed  
computer you may have two screens each with different DPIs. If you  
were to send DPIs to a server, which one would you use? It is for  
reasons such as this, that I believe, that it is important that it  
the responsibility of the local system to work this out, with the  
appropriates hints from the web page.

Andre

On 7-Jun-07, at 16:38 , Maciej Stachowiak wrote:

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