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

On 7 Jun 2007, at 16:28, Peter Speck wrote:

> Why force a "next size up" if most UAs prefer a dpi which is "close  
> enough"?

Do they? I guess it depends. I don't mind spending the bandwidth for  
better looking graphics, but someone on a pay-as-you-download phone  
most likely would.

> All the other Accept-XXX headers (except Accept-Ranges) uses a  
> wildcard if other values are accepted, e.g. (RFC 2616)
>   section 14.2:  Accept-Charset: iso-8859-5, *
>   section 14.3:  Accept-Encoding: gzip, *
>   section 14.4:  Accept-Language: da, en, *
>
> All 3 supports adding a "quality value which represents the user's  
> preference for that charset/...".  Could this be used to allow the  
> UA to tell the server if it wants a "higher up" or "closest"?

something like "Accept-Resolution: 200; allow-closest" to allow  
180dpi images to be sent, and "Accept-Resolution: 200" to get the  
240dpi images? I can't see a way to shoe-horn q= parameters into  
doing this in any meaningful way.

An asterisk would be implied because there will always be a closest  
match, even if the only resolution is lower than a client requested.  
(i.e. There would be no 406 errors because of this header)

> I assume this would be used too when printing a web-page, so the  
> printed output can use high-resultion images.  (I've implemented a  
> page which uses high-resolution GIFs for icons, and it is a pita to  
> maintain).

I'd be interested in seeing that, just for curiosity's sake.

> But how are the browser going to know which files it should re- 
> request when printing the page? All, or only those with a "Content- 
> Resolution"?
>
>> • A "dpcm" (dots per centimetre) parameter could also be  
>> understood by both ends and converted as necessary.
>
> As a web-server implementor, I would prefer keeping the standard as  
> simple as possible (i.e. KISS), especially with options almost no  
> browsers are going to use. Your scheme for selecting the proper css  
> file works spendid with dpcm values converted to dpi.  If a  
> webserver wants to support .css files named using dpcm, e.g.  
> "default.30dpcm.css", that's fine, but don't make the protocol more  
> complex. Continuing with this, I would remove "dpi" from the header  
> value, and simply define both headers value to be dpi.

Yeah, you're probably right, but we're supposed to be moving to  
metric at some point in the 1970s, which i'm looking forward to. Did  
you hear the U.S. plan on landing men on the moon?!

- Nicholas.