Re: Navigator standard change proposal

On Feb 13, 2014, at 8:35 AM, Predrag Stojadinovic <predrags@nvidia.com> wrote:

> 
> I strongly disagree that it is in any way a browser developers fault when we, the web developers, do something wrong with a useful feature or with useful information.
> I simply can not agree with that assesment or view.
> 

Whose ‘fault' it is is irrelevant. None of this is about web or browser developers either. It’s about not punishing the end-user for some web developers’ mistakes. 

No browser vendor wants to tell end-users: “Yeah, you could shop on amazon.com with the last release and it no longer works now. But it’s not our fault; amazon is doing it wrong! Hopefully they’ll fix it whenever enough of you use the new release *and keep using it it despite the fact it no longer works on sites you use* long enough for them to care”. What the user will do is switch to the browser that works i.e. the browser that doesn’t punish them for arcane developer mistake(s) they do not and should not have to understand. Which is to say: the browser that shields users from developer mistakes has, in fact, a competitive advantage. As a result, browsers will not prioritize the Navigator object over compatibility anymore than they’ll refuse to render invalid HTML (even though some people once argued that would be A Good Thing).

There are also intranets where a browser update that no longer works with an internal business app will not be deployed, period; this kind of compat risk is the #1 reason aging versions of IE are so prevalent on intranets as well as the core motivation for IE's Compatibility View, the #1 job of which is to be good enough to allow business users to upgrade Windows and IE without breaking compatibility with the 8-year-old 3rd-party payroll web app their HR department depends on. 

End users’ success and satisfaction take precedence over Navigator object quality as perceived by the far smaller number of people who build web sites, and that has been and remains a very good approach for the web. 

> 
> 
> -----Original Message-----
> From: Adrian Roselli [mailto:Roselli@algonquinstudios.com] 
> Sent: 13. februar 2014 16:52
> To: Predrag Stojadinovic; public-html@w3.org
> Subject: 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.
> 
> [...]
> 
> 
> 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.
> -----------------------------------------------------------------------------------

Received on Thursday, 13 February 2014 17:58:25 UTC