W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Mon, 06 Feb 2012 19:19:35 -0000
Message-ID: <op.v89umxj1ewg2x1@bxr>
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  

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.
Received on Monday, 6 February 2012 11:19:35 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC