[whatwg] RWD Heaven: if browsers reported device capabilities in a request header
miket at opera.com
Tue Feb 7 14:45:38 PST 2012
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
>> of the market (which is what happens with new UA strings right now).
>> 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
> there anyway, the assumption must be that the device can't send these
> headers. In what circumstances might this cause breakages? And how could
> possibly lock out any devices? This is a progressive-enhancement type
> not a "if you don't have the ability to notify the server you can't get
> 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
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:
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.
More information about the whatwg