Re: Navigator standard change proposal

On Thu, 13 Feb 2014 12:09:22 +0100, Predrag Stojadinovic  
<predrags@nvidia.com> wrote:

This is long, and may not make you any happier. It certainly doesn't hold  
out hope that browsers will make the change you are asking for. But it  
attempts to explain why things are the way they are.

[...]
> Let me also say to Charles that yes, the comments were objective, thank  
> you, but unfortunately I also have to say that they are illogical. One  
> example is the Opera 9.8 issue you mentioned, where it simply makes no  
> sense to mess up the navigator.appVersion attribute value in order to  
> accommodate bad sniffers. That decision is doing more harm than good.

Quite possibly. However it was a matter of commercial survival for Opera.  
The cost of giving developers the power you are asking for was that far  
too many sites would stop working due to developer error, and therefore  
users would abandon the browser.

So the logic applied was the rather basic logic of self-interest. Which is  
the logic applied by all browsers in this case.

> Let me also answer the one question that Charles posed which is relevant  
> to the issue at hand, namely “how to ensure that if you rely on a  
> feature, and it isn't present in the user's environment, you can adapt  
> what you do, or at least inform the user about the problem?”.
>
> The answer is certainly NOT the Navigator object. The answer IS feature  
> detection.

OK. Let's establish this as a common point of agreement...

> [...] Anyone who argues that browser detection should be used instead of  
> feature detection is simply wrong. But so is anyone who claims that  
> browser detection should be completely disabled: because it is also an  
> undeniable fact that feature detection is not the ONLY thing that  
> browser detection CAN be used for. There are examples of good use of  
> browser detection. There are actually examples where browser detection  
> is not only good but also necessary, and I gave those examples and I  
> will give a few more below.

In passing I will note that "mobile browser detection" isn't one of them.  
Yandex - a company that makes a lot of front-end tehcnology and has many  
thoughtful and hard-working developers recently had to fix an issue for  
Firefox because we were sniffing for mobile devices - wrongly.

Which is not unusual - browser sniffing for mobile devices has turned out  
to be awful for users.

> It is like when some idiot hangs a piano to his Harley and drags it over  
> endangering both himself and all the by-passers, that we then ban all  
> Harlies because they can be mis-used…

Not quite - because the people enforcing the ban in this analogy would be  
Harley-Davidson.

A more accurate analogy to the situtation would be if a quirk of the road  
rules required motorcycles to have a towing hitch, which people had often  
used to tow inappropriate loads, *and* if the motorcycle manufacturers  
were regularly held liable for the damage done by these loads.

And the response is something like having a towing hitch, but connecting  
it with something like post-it adhesive, so if you try to put a load on  
it, it will fall off immediately. *Obviously* this removes a useful  
functionality from the product. But if the liability cases are putting the  
manufacturer's business at risk, they're likely to judge that as better  
than going out of business.

> Here is an actual case that really did happen to me:
[...]
> So, how does feature detection solve this problem?
>
> It doesn’t. But browser detection did.

But so would testing in a few browsers. Many people argue that there are  
only 3 or 4 browsers you need to test in, but this is patently untrue.  
There are several concurrent versions of IE in use, markets like the BRICS  
have browsers that American and European developers have never heard of or  
which aren't important in those markets. But there are still exponentially  
fewer browsers in use than there are developers who are making mistakes.

Most browsers now employ a *team* of people to deal with developers'  
mistakes (for example, that is Karl Dubost's job at Mozilla, and before  
that he did the same job at Opera). Despite this extensive commitment of  
resources, browsers can afford to blow off most developers, whereas most  
developers cannot afford to blow off most browsers.

Their judgement is that it is easier for developers to test in multiple  
browsers than for browsers to patch all the sites that get this wrong.  
This is reinforced by simple economics, and a cursory analysis suggests  
they have made the right call for them, and for users.

> My other two previous examples where feature detection does not help,  
> but browser detection does, were both acknoledged as valid but then  
> simply ignored. Why?

I believe one was determining when a browser is mobile, and the same  
answer applies. I must have missed the other example. If I find some time  
I'd be happy to look at it and see what is going on.

> I think someone actually said the way to go is to file a bug against the  
> browser. This is a ridiculous suggestion.

No, it isn't. But you are right that it won't necessarily solve your  
problem very fast.

[...]
> What options are there for the developer of a high traffic website at  
> that moment?
>
> a)      To bother ALL users with a message saying “If you are using FF  
> 47.3 then…” ?

I agree, this isn't all that clever.

Although it has the minor benefit of also deterring people who were  
thinking of switching to FF 47.3 if they think your site is more important  
than the one that wasn't working with their current browser.

> b)      To just file a FF bug and HOPE that his FF users will not leave  
> and go to his competition until FF fixes the bug ?

If you *just* do this, and the problem is serious, you're not being very  
smart :)

But as you noted, filing a bug is still a sensible thing to do.

> c)       To rewrite his entire code in order to handle this one FF bug  
> all over the place ? (IFF this is even possible to do) (and also do so  
> whenever any bug in any browser occurs)

If this bug has a big impact on your business, then you should indeed do  
this.

The Web as a platform gives better "market access" for your effort than  
pretty much anything in history. And at W3C we work to make this so, and  
even improve it. But there is no "natural right" that things should be  
easy. W3C has no real enforcement mechanism to change the Web - it  
succeeds by doing things well more than badly, and producing results that  
are sufficiently better than the alternatives for enough people that they  
keep working on the Web.

> d)      OR to just add one simple line of code very quickly and handle  
> it:
>
> a.       if(navigator.browserName===”Firefox” &&  
> navigator.browserVersion===”47.3”) { xyz.inform(“…”); }

All other things being equal, this would indeed be the best option for  
developers to have.

But all other things are not equal.

> Apparently, from reading the answers here, options a), b) and c) are  
> somehow preferable to d)…?

"Preferable" only makes sense if you look at who is doing the preferring.  
And for browser makers, the answer is "yes, unfortunately it is preferable  
to make life a bit harder for good developers, because the impact of  
letting bad developers do (d) is really really bad. Especially for us, but  
also for the Web at large, which makes our enlightened self-interest a  
reasonable thing to push for".

> I honestly fail to see how we can even be discussing this.
> It seems as if you treat web-apps the same way as desktop apps: wait for  
> the upgrade and hope for the best…?

There are some differences.

Desktop OSes (other than Linux distributions) don't really work to provide  
compatibility with each other on a common platform.

The cost of changing browsers is non-trivial, since it requires learning a  
new interface, dealing with a slightly different set of functionalities,  
and downloading some code. In a large organisation doing something  
important like running a factory, the re-training, and the security  
analysis, add significantly to the cost. Large organisations spend literal  
millions of euros to safely change from one free product to another, and  
the cost of inefficiencies or downtime introduced can often be an order of  
magnitude greater. Nevertheless, all of this is chump change compared to  
the cost of changing operating systems.

But in large part "if you want to make a product, then making it work is  
your responsibility" applies to both types of system. The rapid evolution  
of browsers brings benefits to the Web, but it obviously doesn't come with  
no cost to anyone.

> Charles and Adrian, what problems does browser detection cause for the  
> users?

Sites that don't work. *LOTS* of them. When there is no good reason. In  
very many cases the user's browser supports what the site actually uses,  
*and* what the site is using is unnecessary and irrelevant to the user's  
needs. But the massive bug lists for site compatibility are real, and  
generally only the tip of the iceberg.

> Please give me an example, but one where the problem is not caused by a  
> bad developer.

As far as I know, there are no problems in this class. But then, problems  
for users are only caused by a few players - bad browsers, bad developers,  
bad infrastructure, bad hardware.

Of those, bad developers are far the most numerous (without implying any  
judgement on the good/bad ratio in any of these groups). For browsers,  
these problems are generally the ones that have the biggest impact on  
competition (bad networks tend to affect everyone equally modulo issues of  
net neutrality, bad hardware likewise and is usually dealt with fast by  
programming around it - the same thing you don't want developers to be  
forced into). They are also generally the ones that are most expensive to  
fix, so a way to reduce the frequency they appear can be fairly expensive  
(e.g. in goodwill from developers like you) and still a net win.

> How does keeping the Navigator object artificially wrong keep many sites  
> on the web from breaking?

It allows browsers to provide compatibility by rendering simplistic  
browser-sniffers inoperative. Simple sniffers are easier to deal with, and  
perceived as more likely to be the cause of problems since people capable  
of implementing complex browser-sniffing are considered *more*likely* to  
get it mostly right.

This lets browsers focus more effort on implementing the things that sites  
actually rely on, instead of *exponentially* increasing their already  
significant investment in finding, debugging, and getting every incorrect  
browser-sniffer changed.

A corollary is that browser-sniffing is more complex than necessary, which  
makes the compatibility groups' job harder. The "market consensus" is that  
this is still cheaper than the alternative.

> This claim really makes no sense. I don’t see any death spiral here, I
> only see attempts to justify doing something wrong in order to prevent
> some bad programers from doing something wrong while at the same time
> completely ignoring all the good programers that will do something
> right.

I don't think anyone suffers from the illusion that making the Navigator  
object ineffectual makes life easier for all developers all the time.

I understand that you don't see the "death-spiral". It is clearly visible  
in the balance sheets of all browsers, where masses of code and developer  
time is spent dealing with site compatibility, and large amounts of that  
comes from something as simple as mis-use of the Navigator object for  
browser sniffing.

> You are mis-using bad developers to justify bad specification. (pun  
> intended)

I don't know if what is "justified" in any absolute sense - although in my  
judgement it is logical.

Let's put that in perspective. Yandex is used by nearly every russian who  
is online. Adapting our many services to all the browsers used is  
expensive work, and we'd love to reduce that cost. But we understand the  
argument.

I am running our own browser. YaBrowser 14.12 (get it at  
browser.yandex.ru/beta </plug>). For the simplistic test case attached it  
gives

[[[
appVersion: 5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36  
(KHTML, like Gecko) Chrome/32.0.1700.68 YaBrowser/14.2.1700.9974  
Safari/537.36

appName: Netscape

userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)  
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.68  
YaBrowser/14.2.1700.9974 Safari/537.36
]]]

> These are the facts of the matter:
>
> 1)      There are very important problems that can occur, which feature  
> detection simply cannot solve, ever.

Agreed.

> Browser detection allows developers to quickly handle these problems and  
> inform their users about it.

I agree that there are a class of problems for which this is true.

> Why is everyone simply ignoring this fact? Is it not true? Are my  
> examples false?

I don't think anyone ignores, or argues that these 2 statements are not  
facts.

> 2)      Preventing bad developers from making mistakes is noble and fine  
> but ONLY when it does not affect all the other good programmers in a  
> negative way.

On this we have a serious disagreement. It is unclear to me what sort of  
argument would convince a software manufacturer to allow their software to  
be used in such a way that it puts their business at risk.

And that, for browser sniffing from the navigator object, is about how the  
issue is settled.

> And 1) proves that this in fact is the case.

Not in any logic scheme I know of. You're somehow relying on an assumption  
that isn't documented, but appears to be "browsers should make it easy for  
developers to do whatever they want". Developers would love that, just as  
browsers would love to work with the rule "any site which fails to conform  
to relevant standards will be closed down". But neither of those apply in  
reality.

> Feature detection is not sufficient. Feature detection is the best  
> solution for feature detection, as is a UHAUL truck for carrying a  
> piano, but not much of a chick-magnet…

> Web-apps are not desktop apps. With browsers changing daily, web  
> developers have to react, FAST.

Sure. And with developers and other browsers innovating, so do browsers.  
In fact they don't just react, both groups actually create new things.

> Bad programmers doing bad things is a bad reason to have a bad Navigator  
> object or to ban it all together.

Perhaps. But the alternatives appear to be far worse.

> The Navigator object, if defined properly, would be a very useful helper  
> for GOOD programmers when handling problems for which feature detection  
> is not sufficient.
> Much like a Harley is a way better chick-magnet than a UHAUL truck…
>
> It really is that simple.

Unfortunately not.

I don't know if you've done any A/B testing with women (or any reasonably  
large set of people) who own pianos, comparing telling them you will move  
their piano
  a) by dragging it behind your Harley
  b) in your UHAUL truck.

I haven't, but I'll bet a fair bit of money on the outcome of any  
moderately objective version of such a test.

Likewise, nobody stops people from taking an open-source browser codebase,  
and modifying the information it gives to be brutally honest. But every  
browser I know, whether it started doing that (as many did) or not, has  
concluded that it is a bad idea. And arguments based on cost/benefit to  
the browser seem to run very clearly and strongly in a single direction.

Because we are all interconnected here. Which means our problems don't  
exist in isolation. Which means the solution normally has to deal with  
various complicating factors, and possibly isn't the one we would have  
chosen for a simpler ecosystem.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Thursday, 13 February 2014 13:37:57 UTC