[webkit-dev] Accept- & Content-Resolution headers proposal
ajmas at sympatico.ca
Thu Jun 7 13:52:10 PDT 2007
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.
On 7-Jun-07, at 16:38 , Maciej Stachowiak wrote:
> On Jun 7, 2007, at 1:26 PM, Rob Burns wrote:
>> 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
More information about the webkit-dev