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

[Mike Taylor]

On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox  
<mail at matthewwilcox.com> wrote:

>> , will cause their users to get more broken pages (which is what happens
>> in many cases with browser sniffing right now), will lock new devices  
>> out
>> of the market (which is what happens with new UA strings right now).   
>> And
>> hence that the proposal is bad for the web in various ways.
>>
> I'm not sure what your grounds are for thinking this. Would it not be
> sensible for the server to have to serve some default if the headers  
> aren't
> there anyway, the assumption must be that the device can't send these
> headers. In what circumstances might this cause breakages? And how could  
> it
> possibly lock out any devices? This is a progressive-enhancement type  
> tech,
> not a "if you don't have the ability to notify the server you can't get  
> any
> info" type tech. Surely?

"Progressive-enhancement type tech" gets abused as well. Take the <video>  
element, with its lovely <source> elements for codecs and fallback content  
for non-supporting UAs. No hacks necessary. Then throw laziness and  
javascript at it and you've got a mess.

An example, visit http://www.maerskfleet.com/ with an empty UA string (or  
use Opera). In a browser that should be able to support <video>, you'll  
get a JS error and the page is blank. Even after including Modernizr and  
using HTML5 which is designed to gracefully degrade for older UAs,  
developers do the same old UA sniffing trick:  
https://gist.github.com/1761168

I would love to believe that all developers would use this proposal "for  
good", as it were. Experience leads me to believe it will be just another  
technique sniffed and served to the regular suspects.

-- 
Mike Taylor
Opera Software