[webkit-dev] Accept- & Content-Resolution headers proposal
contact at nickshanks.com
Thu Jun 7 13:53:29 PDT 2007
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2427 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070607/b7200c84/smime.bin
More information about the webkit-dev