[webkit-dev] Accept- & Content-Resolution headers proposal
robburns1 at mac.com
Fri Jun 8 10:07:04 PDT 2007
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.
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).
> 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
More information about the webkit-dev