On Mon, 06 Feb 2012 18:58:00 -0000, Boris Zbarsky <bzbar...@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
