RE: Navigator standard change proposal

I don't mean to drag this thread out. Chaals has already responded to the bulk of this in far better detail than I could, but I am going to address where you mention me directly and also what I think is a flaw in your example scenario...

> From: Predrag Stojadinovic [mailto:predrags@nvidia.com] 
> Sent: Thursday, February 13, 2014 6:09 AM
[...]
> 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.
[...]
> 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…" ?

Having worked with users for years, they typically don't know what their browser version is, let alone what browser they are using. You may have had this experience as well. Sure, it's anecdotal, but I'd bet we can dig up some numbers that support it.

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

There is no reason this cannot be done as well. It should be done anyway.

> 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)

Yes. This should be considered and, if it makes sense, done in conjunction with (b).

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

Sure, you can do that, but at some point you will find that you need to go back and adjust it. Assuming the user experience is so important, that's an ongoing task for which you or your client will need to pay. If you don't believe that at some point you'll need to update that, look at the historical evidence which you have already acknowledged.

Let's not forget that in your example you cited a specific plug-in that was causing things to break in a particular browser release. This approach shuts out all users of the browser version, not just the users of the offending plug-in. In essence, you are blocking more users than is warranted because this approach is so easy, not because it's correct.

If anything it is proof why UA detection is a shotgun approach to an issue that requires a far more nuanced and multi-faceted approach.

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

I don't see why you wouldn't consider doing (a), (b), and (c) regardless of whether or not (d) was even viable. In a perfect world of an ideal Navigator object, *you still need to do those first two (or three) steps*.

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

Not at all. Code around the issue. When possible.

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

In a vacuum, none. In the hands of developers, lots.

Given your example above, you are making an assumption that (d) is the best approach and perhaps the only approach, when in reality you should be considering all of them. In short, having the Navigator object doesn't reduce the work *you* need to do, if anything it creates more work for you down the road and, if you don't do that work, may eventually harm your users (see all the other emails about the Firefox and Opera teams trying to get sites to fix their broken code).

So, here's my response in a nutshell:

UA detection shouldn't be done in a vacuum given its current state and historical track record. All the other workarounds still need to happen. Adding UA detection as a solution builds in the need for ongoing maintenance without removing the need to still perform the other workarounds.

By leaning on UA detection your are just adding work, not reducing it.

[...]

Received on Thursday, 13 February 2014 15:52:27 UTC