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 23:47:30 -0000
Message-ID: <op.v8961gx8ewg2x1@bxr>
On Mon, 06 Feb 2012 20:08:05 -0000, Matthew Wilcox <elvendil at gmail.com>  
wrote:
> On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
>> We're discussing HTTP here, so the content might just as well be raster  
>> bitmaps.
>
> Are we? Why, what makes HTTP the relevant factor? SPDY is the future and  
> already supported in two major browsers., As it compresses headers and  
> multiplexes, I don't see the issue.
>
Sorry, my bad. We're discussing an application layer client/server  
protocol that can be used for transferring files that don't use CSS pixels.

>> 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.
>
> No, it means we as a standards body define which gets sent. The sensible  
> thing is to send the maximum screen size in use on the device.
>
This is usually, but not necessarily known on page load. I think static  
viewport resolution and screen size is the 80% case we should optimize  
for, but others (who presumably print documents more often) disagree.

> Again, read the proposition I mentioned and you'll find non of this is  
> true. Extra headers would only be sent by the browser if the browser  
> received a request for the client to send those headers.
>
Presumably, this would be decided upon authority-wide (in the URI sense)?

Trying to allow the application layer client/server file transfer protocol  
stateless may be overly purist and impractical, but I think highly  
descriptive <object>s are a better solution.

-- 
-,Bjartur
Received on Monday, 6 February 2012 15:47:30 UTC

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