On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox
<[email protected]> 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
