RE: Navigator standard change proposal

I cannot address each response individually. I apologize if I missed something, it is not intentional.



Let me first say thank you to Charles for explaining why appCodeName and product attributes are there. I do have a comment on that but I will keep it to myself in order to not stray off the topic again…



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. But again, I digress…



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.

I would never claim that the Navigator object should be used instead of the feature detection in THAT case. Same goes for many other similar cases.

I believe I did already emphasize this in my previous response when I said: “Of course feature detection is better than browser detection, in those cases.”



But, this example actually perfectly illustrates why I refer to this as a Red herring: It is an undeniable fact that browser detection should NOT be used instead of feature detection. 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.



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…

And before you complain, this Harley/piano example is not a straw man of your argument because you actually are arguing for a removal of something useful simply because it can be mis-used.

Guys, this is not an argument. It really isn’t.



Here is an actual case that really did happen to me:

Several weeks ago my web-app was crashing in Chrome but only if the iMacros plugin was installed. Without it the web-app worked as expected. Nothing was in the console log, other than an error from the iMacros plugin. And this didn’t crash other websites we tested.

In Firefox with iMacros plugin, the web-app worked as expected.

In IE with iMacros plugin, the web-app worked as expected.



So, how does feature detection solve this problem?

It doesn’t. But browser detection did.


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 think someone actually said the way to go is to file a bug against the browser. This is a ridiculous suggestion.

Also, are you claiming that it is impossible, for example, to simply have a bug in FF 47.3 which causes feature detection to say something is available and then have this feature crash the site?
From arguments I see here, the suggested solution is to just let both users and developers hang and wait for FF 47.4 and hope the bug will be fixed.

Ofcourse a browser bug should be filed, who in their right mind would argue against that.
But how is that an immediate solution for the developer and the users of his high traffic website? It isn’t.

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…” ?

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 ?

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)

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(“…”); }

Apparently, from reading the answers here, options a), b) and c) are somehow preferable to d)…?
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…?


Charles and Adrian, what problems does browser detection cause for the users?
Please give me an example, but one where the problem is not caused by a bad developer.

How does keeping the Navigator object artificially wrong keep many sites on the web from breaking? 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.

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


These are the facts of the matter:


1)      There are very important problems that can occur, which feature detection simply cannot solve, ever.
Browser detection allows developers to quickly handle these problems and inform their users about it.
Why is everyone simply ignoring this fact? Is it not true? Are my examples false?


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.
And 1) proves that this in fact is the case.


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.
Bad programmers doing bad things is a bad reason to have a bad Navigator object or to ban it all together.

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.


Thanks,

[cid:image001.png@01CF28A0.ED3DEA50]

Predrag Stojadinović  | T +49.2405.4.78246  |  predrags@nvidia.com<mailto:predrags@nvidia.com>
NVIDIA GmbH, Adenauerstr. 20 A4, 52146 Würselen, DE  |  http://www.nvidia.de<http://www.nvidia.de/>








-----Original Message-----
From: Adrian Roselli [mailto:Roselli@algonquinstudios.com]
Sent: 12. februar 2014 18:46
To: Predrag Stojadinovic; public-html@w3.org
Subject: RE: Navigator standard change proposal



> From: Predrag Stojadinovic [mailto:predrags@nvidia.com]

> Sent: Wednesday, February 12, 2014 12:07 PM

>

> > > o What is gained by not allowing web developers to detect the

> > browser which their code is going to be executed in?

> >

> > History suggests it will be mis-used. Some developers equate

> > browsers and versions with certain capabilities, and so far evidence

> > has shown that is repeatedly wrong. That's how we moved to feature

> > detection instead of browser sniffing in general as an industry.

> >

> > Heck, we've seen it pop up in the relatively new world of trying to

> > detect mobile browsers by UA, and it fails consistently. [1]

> >

> > Browsers have moved to supporting standards better than ever before,

> > so coding for one browser is mostly unnecessary. Doing so can lead

> > to the same mess we are seeing with cleaning up CSS browser-specific

> > prefixes.

>

> - So, it is up to the standard to prevent the users from misusing it?



No, it is not up to the standard. However, when *years of evidence* suggest it doesn't work, then stop arming developers with features that ultimately hurt users through poor implementation.



> As I explained already, how the developers use the information

> provided is on them. My proposal deals with the simple fact that the

> Navigator object does not do what it is supposed to do, that is to

> provide the information about the browser and engine used.



You are correct. The Navigator object doesn't do what it was originally intended to do. Because it cannot.



> Also, the point about trying to detect mobile browsers by UA is

> exactly the reason why the Navigator object should be improved, so

> that the UA does not have to be parsed.

> Thank you for proving my point.



Ok, this is odd. I don't know how you think I proved your point. The Navigator object will simply be mis-used again. It already has to be kept artificially wrong to keep many sites on the web from breaking. They break because people were using it incorrectly.



Do you see the death spiral  here?



> > > o What is gained by protecting browsers that do not provide

> > established standards?

> >

> > I don't understand. There aren't established standards and no one is

> > protecting anything. Unless you can point me to something that says

> > otherwise (although IE has standards for its UA string [2], if

> > that's your beef).

>

> - My only "beef" is with the Navigator object standard errors. My

> other "beef" was with a Microfost employee coming into this discussion

> to promote his browsers agenda, instead of objectively addressing the

> issue. Either way, this is going off on a tangent…



I think you mis-read his post.



> And as above with [1], the [2] simply proves my point: UA sniffing is

> wrong.



Ok, so we agree UA sniffing is bad practice.



> And why did UA sniffing come about? Because the appName and appVersion

> were poorly defined and thus unusable.



No, appname and appVersion became poorly defined because of UA sniffing. They had to be locked in to keep sites from breaking.



You have your cause and effect reversed here.



> So, the question is, should the Navigator object be properly defined

> to eliminate the need for UA sniffing or not?



Again, I believe your cause and effect reversal is over-complicating this. Properly defining the Navigator object will break legacy (and some current) sites. Developers will start to lean on it again for UA sniffing (regardless of its intent). Then as sites are no longer maintained, natural changes to the Navigator object will cause sites that do UA sniffing to break.



Lather, rinse, repeat.



> > > The Navigator object standard is, to put it mildly, a complete

> > > mess and really has to be fixed.

> >

> > I agree on the first point and disagree on the second point. It

> > should be made obsolete.

>

> - I disagree with its removal as it is not up to anyone to hide

> valuable and useful information from developers.



I think that already happens. Look at the discussion for hiding whether or not a user is utilizing a screen reader. Many don't want to expose that due to both privacy concerns and, yep, UA-style sniffing. Ok, that may be a bit of an outlier...



> Nowhere did I disagree that libraries like Modernizr and others should

> be used.

> Nowhere did I argue that browser name/version is better than feature

> detection.

> Of course feature detection is better than browser detection, in those

> cases.

>

> But the feature detection issue is a Red herring here.



I don't think it is the red herring. I think it's the reason we are where we are. You can't move forward without understanding how we got to where we are.



> The feature detection is not the issue, the issue is the Navigator

> object, it's purpose and definition.

>

> The fact remains that many developers simply want to know the browser

> & version information and they should be allowed to know it, no matter

> how they want to use it, no matter what they want to use it for.

> This is not and should not be our concern here.



Is it safe to assume that getting this date from Google Analytics doesn't satisfy your scenario? That you want to be able to change the page in some way based on the Navigator object?



If so, can you identify use cases that you cannot otherwise achieve with the techniques currently in use?



> > > And as I stated in my original suggestion, the most sought after

> > > information is completely obfuscated and hidden for no security or

> > > any other objective reason.

> >

> > What you see is the vestigial remnant of browsers needing to support

> > poorly-coded sites that relied on UA detection. It's probably the

> > best argument for why it should be made obsolete.

>

> Poorly coded sites?

> You do realize that there are issues with browsers that are simply not

> detectable with feature detection?



Yes. Every day.



> For example, the handling of the hash url redirect is one of them.

> Another example is the Compatibility view and the fact that certain

> thing simply do not work as expected even if detected to be available.



Yes. I have written on these issues repeatedly for ~16 years now.



> But again, this is all a Red herring.

> What developers decide to do with the information obtained is up to

> them.

>

> And after all, the fact still remains that the Navigator object is

> very poorly defined and that this is a problem.



Or, perhaps, the solution.





NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------