[whatwg] RWD Heaven: if browsers reported device capabilities in a request header
svartman95 at gmail.com
Mon Feb 6 15:47:30 PST 2012
On Mon, 06 Feb 2012 20:08:05 -0000, Matthew Wilcox <elvendil at gmail.com>
> On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
>> We're discussing HTTP here, so the content might just as well be raster
> 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.
More information about the whatwg