[webkit-dev] Accept- & Content-Resolution headers proposal
mjs at apple.com
Thu Jun 7 13:38:46 PDT 2007
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.)
> Take care,
> 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
>> 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.
> Take care,
More information about the webkit-dev