On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox
<m...@matthewwilcox.com> wrote:
I've asked Bruce Lawson (one of the Opera boys) about this, and it's not
likely to happen with HTTP. However, SPDY compresses headers as well as
multiplexes, and it's a much more realistic request to get useful headers
sent over a SPDY connection than it is over HTTP.
As for how useful it is - it's very very useful. Traditionally I don't
think the requirement to adapt content assets to device capability has
been
that important, because other methods were available (including the
god-awful mess of the UA string). That's going to be less and less useful
as the variety of devices continues to balloon and the UA string becomes
less and less sane.
We need the server to know about the device. We need headers.
I'm pretty sensitive to Henri's argument that it's easy to add headers we
think will be useful, when they really won't. They are still a pretty
expensive part of the transaction, especially for mobiles.
If you want them anyway, you might like to look at the Device Description
Repository work W3C did, building on the lessons learned from doing CC/PP,
UAProf, WURFL, because "the mobile web [had/was about to] reached the
point where this capability was really important".
More to the point I thin it is clear that developers want to know how to
adapt their content to the user's device (rather than trying to adapt the
user to buy the device they coded for which I think many people here would
agree is a really bad thing to encourage).
There is also the approach of knowing what capabilities you have from
within the page itself. Again there is a long history of this, including
media queries, the generally loathed hasFeature in DOM and the more common
if (navigator.something) approach that is widely used instead, and so on.
cheers
Chaals
--
Charles 'chaals' McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
