Re: [webkit-dev] Accept- Content-Resolution headers proposal
Hi, Does Apache support Feature negotiation as specified in RFC 2295 (see http://www.ietf.org/rfc/rfc2295 )? If so, is there any documentation related to this (I couldn't find any)? If not, are there any plans to support this portion of the RFC? FYI the back story to this request is from a discussion regarding having images served to a client dependant on its resolution and/or viewport width. Normal browsers may get an the image as 600px across, small screen devices may get an image that is 150px across and browser requesting the image for printing purposed may get an image that is 1200px across. I was able to create a type-map file for the images as follows: URI: image URI: image-1200x1000.jpg Content-type: image/jpeg; qs=0.9 URI: image-600x500.jpg Content-type: image/jpeg; qs=0.5 URI: image-300x250.jpg Content-type: image/jpeg; qs=0.25 URI: image-150x125.jpg Content-type: image/jpeg; qs=0.1 Apache would (correctly) perform server side selection to pick the variant with the highest qs, however I could not find any way of specifying features (such as DPI) for each variant, that would allow a lower qs variant to be selected based on a appropriate request with Accept-Features (e.g. Accept-Features: dpi=[70-100]). Cheers, -- Tom Howard http://windyroad.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accept- Content-Resolution headers proposal
On 07/06/2007, at 22:38, Maciej Stachowiak wrote: The only case that needs to be addressed better IMO is foreground images via img. And that should probably be handled at the HTML or CSS level, not the HTTP level. But the html doesn't know (today) which dpi the display is using. When the server generates the html file to the client, it doesn't know the resolution either. So do you imaging adding Javascript properties to dynamically update img or do you want to add new attributes to the img tag? Or should we replace all of them with div's using backgrounds? Rather than hacking img with special attributes for resolution, I consider Accept-Resolution a generalized solution rather than using one method for css backgrounds, another for img, and then another for object including images that Flash movies might fetch. - Peter Speck ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accept- Content-Resolution headers proposal
On 08/06/2007, at 13:07, Nicholas Shanks wrote: http://www.ietf.org/rfc/rfc2295 [...] 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. [...] 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. This sounds good. I've read the RFC and cannot find any problems, so I dully agree to drop prior proposals. What's the ETA for WebKit implementation? - Peter Speck ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accept- Content-Resolution headers proposal
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
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accept- Content-Resolution headers proposal
On Jun 7, 2007, at 9:00 AM, Nicholas Shanks wrote: Sorry, Accept-Content: text/css, text/dsssl, text/xsl should of course have referred to Accept-Type :-) Actually it should have been Accept:. There is no Accept-Type header. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
