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
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
