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

[Rob Burns]

Hi Nicholas and Peter,

That is great (though ironic) to hear that this feature's been there  
all along (at least in the spec and in the server). I wonder if you  
(Nicholas) could write up or point to some instructions on  
configuring that in Apache (ideally the exact lines to add to the  
config filie).  This would help implementors and just help raise  
awareness for server admins (as the word spreads).

I think the device-pixel-ratio is not really needed in the registry.  
Its a bit of a sidetrack issue.. If design is done through resolution- 
independent units (everything but pixels) and only bitmaps are  
measured in pixels, the difference between device pixels and CSS  
pixels disappears. In other words, the work of some of the proposals  
in CSS 2.1 and the Acid2 tests basically turns pixel into 1/96th of  
an inch (with complicating caveats about much higher resolution  
output devices and viewing angle). All of this means that pixels  
should just not be used except to describe the resolution or  
dimensions of a bitmap image.

The units in an NSView are typically understood as points. In WebKit  
they're understood as pixels instead (which probably became necessary  
to match the scale of page designs to other competing browsers).  
Until resolution independence is finally introduced into Mac OS X the  
two are equivalent so there's no disjoint. As display resolution's  
have increased, the base zoom of displays has decreased. This means  
that with a 96dpi display, the base zoom is at  75% (72/96 =0.75).  
When resolution independence is introduced, the base zoom can be  
whatever the user wants. NSView units will be points in other  
applications, but NSView units will be CSS2.1 pixels (1/96 of an  
inch) in WebKit (which is why one has to scale down by 75%  to turn  
units that are 1-1/3 of a point back into 1 point when printing  
because then the base zoom is expected to be 100% ). Anyway, as I  
said, this was probably necessary just to keep the scale similar to  
other browsers. Otherwise everyone would be asking why pages were so  
much smaller in WebKit than in every other browser (plus, I'm not so  
sure the road to resolution independence was clearly paved when  
WebKit was brought to Mac OS X).

So perhaps some of this could be illustrated on the blog.

* The different treatment of resolution independence in WebKit  
compared with other Mac OS X apps (NSView units are 1/96 of an inch  
and not 1/72)
* The importance of using resolution independent units (not pixels)  
is important. Pixels were bad to use before for CSS. The treatment by  
IE and Acid2 as a fixed 1/96 of an inch (and therefore an absolute  
unit) renders pixels as quasi resolution independent. But that just  
creates confusion (hence the difference between the terms "CSS pixel"  
and  "device pixel"). If we really need a term for 1/96 of an inch  
perhaps someone could coin an neologism for it (I'm  not even going  
to try :-) ).
* Finally, including the Apache configuration to make that convenient  
for server admins and browser developers for testing (after all, as  
Nicholas said the reason we thought we had to reinvent the wheel is  
that Apache didn't include this in the standard configuration).  
Getting Apple and other Apache distributors to add this to the config  
file (even if commented out) would be a good approach.

Take care,
Rob

On Jun 8, 2007, at 6:07 AM, Nicholas Shanks wrote:

> Hi Peter.
>
> I recommend you take a look at what Larry Masinter pointed out. It  
> becomes clear that all of this has already been solved 9 years ago,  
> but because it (apparently) isn't enabled in Apache by default, I  
> and many others never even realised it existed:
>
>> Content negotiation for HTTP based on parameters beyond MIME types
>> was the focus of a significant amount of IETF work, including
>> RFC 2295 ("Transparent Content Negotiation in HTTP")
>> RFC 2296 ("HTTP Remote Variant Selection Algorithm -- RVSA/1.0")
>> and a set of 'media features' (including resolution, screen
>> size, pixel depth, etc.) in a Media Feature registry
>> (RFC 2506, BCP 31).
>
> http://www.ietf.org/rfc/rfc2295
>
> Basically the client adds a "Negotiate: trans" header to the GET  
> request, and initiates transparent (to the user) content  
> negotiation (TCN). The server sends back a 300 response with a list  
> of choices in an Alternates header, the format of which is defined  
> in the RFC. The client then issues a new GET request for the one it  
> wants, without having to send any environment information (dpi,  
> &c.) to the server.
>
> Clients can also send a few (small) Accept-* headers and ask the  
> server to take an educated guess, but still return the list of  
> Alternates along with it's guess, which could save round trips if  
> the client decides that the server's guess was good enough ("the  
> 150dpi would have been best for me, but I'll just use this here  
> 200dpi image you've already sent"). If the resource is non- 
> negotiable, the Negotiate header is ignored by the server and  
> nothing changes.
>
>
> In light of this, I suggest that WebKit developers (including me if  
> I get the time) look into implementing this set of RFCs, and ignore  
> all previous suggestions.
> It seems we've been in the classic chicken-and-egg situation since  
> 1998, where clients don't implement it because servers don't have  
> it turned on by default, and servers don't have it enabled because  
> there are no client implementations to test against. Website owners  
> are left none the wiser, and while a few server-side negotiation,  
> most don't find it reliable enough to use, and have things like  
> flag icons on their home page to choose your language.
>
> Apple members should discuss with the IETF the addition of device- 
> pixel-ratio to the Media Feature registry. This will allow TCN for  
> <img> and <object> elements containing visual media, and anywhere  
> else where CSS does not apply.
> I also suggest a "High-Res: Part III" blog post on webkit.org to  
> draw attention to this feature and get more web developers aware of  
> and using TCN, which I think is the biggest hurdle (implementing it  
> won't be as hard).
>
> - Nicholas._______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev