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

[Nicholas Shanks]

On 7 Jun 2007, at 20:58, Maciej Stachowiak wrote:

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

I presume you meant "72 dpi 2x scale" there. In that case just ask  
for 144 in the request. The server doesn't need to know whether it's  
a high res screen or a low res one zoomed in, only how many pixels  
you've got to fill so it can pick the 2 MB photo or the 30 MB photo.

> I think the whole design of it is wrong. It's based on DPI instead  
> of scale factor,

It is based on both, the client apply the scale to the output dpi  
before making the request, so it doesn't ignore scale factor, it's  
pre-multiplied beforehand.

> it pushes the decision to the server when it should be made on the  
> client side

This is a good example and something that cannot easily be done at  
present - client-side selection.
The only way i see to do that would be to preflight each request with  
a GET with "Accept: *;q=0" header, wait for the 406 response, and  
make a second request by selecting from the list given. The server  
would also need to provide the DPI of the images. The problem here is  
for most resources there is only one choice, but you have to make two  
trips to the server for it.

I know of no means for a client to say "I want this resource, send me  
a list of choices if there are any, or the resource otherwise".  
Perhaps there ought to be a CHOICES method that either returns a 406  
list if there are choices, or returns the 200 result like GET would  
have done if and only if there was one choice. CHOICES would never do  
server-side content selection. Then you would only have one request  
for most resources, and two for the negotiable ones, yet do the  
selection on the client side. The problem with GET is it might  
succeed in selecting a resource that you didn't want, and when it  
does, the Vary header isn't detailed enough to tell you what else  
might be more appropriate.

Also bear in mind it's infinitely easier for an administrator wanting  
to deploy high-res images to update his server software than to  
persuade all his users to upgrade theirs! Whilst I can't see a way of  
getting the result without updating both, further refinements on the  
server can improve all clients that send the new header, without them  
needing to update too.

> and it handles things at the HTTP level that should be (and indeed  
> are) handled by CSS media queries.

What about when CSS is not available?
What about when you don't control either the CSS or the image  
resource? (e.g. adverts on a 3rd party server)
What about when you don't know what variants of a resource there may  
be now or in the future?

> What you care about with images embedded in web content

And what about images not in web content?
I agree, use media queries where HTML+CSS is available and you can  
control both the CSS and the images, but you need to fall back to  
content negotiation otherwise.

- Nicholas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070607/b7200c84/smime.bin