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.

Received on Wednesday, 12 February 2014 17:46:04 UTC