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

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.

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.

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

>
>
> The server has the following to choose from:
>
> default.72dpi.css
> default.144dpi.css
> default.288dpi.css
> default.2400dpi.css
>
>
> In this instance, the 144 DPI stylesheet would be returned, because  
> it is the next size up, with a header:
>
> Content-Resolution: 144 dpi
>
> The client would thus know there was a resolution mis-match and  
> (optionally) perform a correction on the CSS values.
> (the mechanism assumes higher is better, and scaling down is  
> preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
> resolution of 160dpi, and so would get the 288dpi stylesheet, even  
> though the 144 is a closer match, and the laptop with a web page  
> zoom of 200% would request 233.33 dpi)

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.

>
>
> Furthermore:
>
> • Images served with a Content-Resolution header could have their  
> resolution trusted (most web browsers today display one pixel on  
> screen per pixel in the bitmap, and ignore the image's internal  
> resolution parameter, if one exists). If they don't match, probably  
> best to use the image's internal one. There could also be a special  
> "Content-Resolution: auto-adjust" header meaning that the server  
> doesn't know the resolution at content-negotiation time, but wants  
> the client to scale it according to the image's internal value  
> anyway, and not do a pixel-to-pixel mapping.
>
> • A "dpcm" (dots per centimetre) parameter could also be understood  
> by both ends and converted as necessary.
>
>
> What do people think? I've only spent an hour or so pondering this,  
> so it won't be bulletproof yet.

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

Regards,
Maciej

Received on Thursday, 7 June 2007 19:58:46 UTC