- From: Bjartur Thorlacius <svartman95@gmail.com>
- Date: Mon, 06 Feb 2012 19:19:35 -0000
On Mon, 06 Feb 2012 18:58:00 -0000, Boris Zbarsky <bzbarsky at mit.edu> wrote: > Again, it's not constant in the terms that the page sees, which are CSS > pixels, not device pixels. > We're discussing HTTP here, so the content might just as well be raster bitmaps. Multiple and variable screen dimensions are quite common (in special for projection). That means a request for every screen the resource may be. For legacy HTTP servers that don't support the new and complicated If-Different-For-Device header that would have to be added would serve the same content once for every screen. So you have UAs sending extra headers with every request, making extra requests with even more extra headers in the fairly common case of variable screen dimensions (multiple screens) and either extra response headers for servers that use the feature (perfectly acceptable) and double round-trip lag (probably terrible) while the UA waits for the extra response header to check if there are alternative versions of the resource for differently sized screens and fetches the alternative version if there is one, or redundant fetching of *all* resources in proportion to the number of possible screen dimensions (assuming the best case of screen dimension being the only variable). This is frightening in so many ways. You're better off discussing some of the details on httpbis though, in special if you intend to propose this formally to the Internet Engineering Task Force. When bandwidth savings are more important than download speed, and for tremendous size deltas (such as for heavy graphics with available downsamples), please consider HTTP 300 Multiple Choices client side negotiation and linking to multiple representations of the same resource. -- -,Bjartur
Received on Monday, 6 February 2012 11:19:35 UTC