Julian,
On Thu, 11 Oct 2012 08:09:07 -0500, Julian Aubourg <[email protected]> wrote:
... so the burden of proof is on *you*. *You* have to establish the
consequences of making a backward incompatible change. Not brush away
arguments pro, or cons, to advance your agenda. Did you ask backend devs
why they white-listed browsers? Did you try and educate them? Did you
ever
encounter any sensible use-case for this? Do you really want to break a
lot
of backends expectations because you "don't see the reason"?
I personally have contacted hundreds of sites for these types of issues
over the past few years. We've done the education, outreach, evangelism,
etc. Success rates are very low, the majority are simply ignored.
We don't have to prove it is useful. We just have to prove it is used and
*you* brought this up yourself. Now you want to bypass this by pretty
much
hacking client-side. Please make a compelling case for it.
I'm sorry but that's complete non-sense. The backend is the provider of
the
data and has all the right when it comes to its distribution. If it's a
mistake on the backend's side (they filter out while they didn't intend
to)
just contact the backend's maintainer and have them fix this server-side
problem... well... server-side.
This isn't feasible. There's a whole web out there filled with legacy
content that relies on finding the string "Mozilla" or "Netscape", for
example. See also the requirements for navigator.appName,
navigator.appVersion, document.all, etc. You can't even get close to
cleaning up the mess of legacy code out there, so you work around it. And
history repeats itself today with magical strings like "Webkit" and
"Chrome".
What of new browsers, how do they deal with this legacy content? The same
way that current ones do, most likely -- by pretending to be something
else.
<aside>
The burden of proof is on you. *You* ha
Emphasis with asterisks seems unnecessary aggressive. Perhaps
unintentionally so. :)
</aside>
Cheers,
--
Mike Taylor
Opera Software
