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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to