Re: Navigator standard change proposal

On Wed, 12 Feb 2014 13:47:27 +0400, Predrag Stojadinovic  
<predrags@nvidia.com> wrote:

> I wouldn't say it encourages so much as it enables browser detection  
> which is what the purpose of the Navigator object actually is.

Yes. And experience shows repeatedly that such a feature causes huge  
long-term problems, and doesn't solve many.

> Instead, it seems that You would rather keep the Navigator object  
> obfuscated and thus completely useless in order to protect Your product?

Actually, my experience suggests this is necessary to protect users.

> I honestly do not understand the issue You are trying to invent here?

To say Travis is trying to invent it is both insulting and inaccurate.  
This is a longstanding issue (I wrote tutorials and explanations about it  
in 1998…)

> · What is gained by not allowing web developers to detect the browser  
> which their code is going to be executed in?

Instead they detect whether the features they need will work. Which  
protects users of any browser the developer didn't know about (in time  
that set generally means "most of the market") from being erroneously  
excluded or told they need to change a product they use for far more than  
accessing one developer's product.

> · Why is such detection implied to be "bad behavior"?

Because in most cases it excludes future browsers, and therefore stifles  
innovation by forcing browser developers to devote increasing resources to  
fixing developers' bugs.

> · What is gained by protecting browsers that do not provide established  
> standards?

Nothing, but the purpose of making browser-detection difficult is to  
protect browsers which *do* adopt standards and enhance their support.

> o   And why is that somehow more important than allowing developers to  
> have control over the user experience?

Immediately, because typically browsers are blamed when sites don't work,  
whether it is a problem with the browser or a problem caused by the  
developer applying a badly-written sniffing script.

More generally, browsers are among the software called *User Agents*  
because they act on behalf of the user. Their long-term interest is  
generally (but not always) served by allowing a user to get what a  
developer offers rather offering the user as a consumer to the developer.

> ·         What is gained by not allowing the developers to inform their  
> users that some of the state of the art features will not be available  
> and that they should install another browser in order to have them?

Nothing. Which is why people have put a lot of effort into enabling useful  
feature detection that doesn't have the harmful side-effects commonly  
associated with browser-sniffing.

> All of the above is what drives the increasing quality of the various  
> products at hand. At least it should be.
>
> If IE was not subpar then it would not have been, as you put it,  
> "targeted" by browser detection.
> I understand that You work for Microsoft and thus feel the need to  
> provide special protection for IE, but I would frankly suggest that it  
> would be much better if this energy was targeted towards improving IE  
> rather than towards stalling development and making developers’ lives a  
> living hell whenever they want their state of the art JavaScript web  
> applications to also work in IE.

This is actually a misunderstanding of history. Browser detection arose in  
the era of Netscape's dominance, and the technique began to cause real  
problems for normal users in the period about 1997-1999. It seems never to  
have got better.

> Please provide justification for Your claim here?

I've tried to explain above...

> The "Ipse dixit" approach is really not useful.

Agreed. But I think that among browser manufacturers this is assumed to be  
well-understood, like "use alt attributes for img elements". So it is easy  
to forget that not everybody in this global community shares that context.

> I honestly hoped for objective comments on this topic, and not the  
> expressions of company loyalty. Please.

I think you're reading far too much into Travis' statement about "company  
loyalty". But the only ways I can see developers would be able to demand  
loyalty from the manufacturers of the software that users rely on to give  
them a market in the first place are to be so important that nobody can  
afford to work against them (which means extracting a monopoly rent,  
something that runs foul of anti-competitive behaviour laws in many  
jurisidictions), or by in turn recognising the need of those  
manufacturers. Unfortunately developers, like users, are a very diverse  
set of very many "individuals" who do not demonstrate the ability to  
reliably implement standards without introducing harmful mistakes.

> The Navigator object standard is, to put it mildly, a complete mess and  
> really has to be fixed.

There has been quite a lot of work on fixing *the problem*. Which isn't  
"make the Navigator object return more accurate strings" (unless you  
accept a solution that introduces massive amounts of fragmentation to the  
Web, thereby increasing the overhead for users as different developers  
demand different browsers - in other words, drop it and go with native  
apps that don't bother working across OS…).

> For example, the appCodeName and product attributes are completely  
> useless. They each have one single fixed predefined value, so what’s the  
> point of even querying them?

None. As Boris pointed out, they are there because there is existing  
content that *does* query them, and if it doesn't get the right answer it  
fails to work. (The right answer typically includes words like "Netscape"  
and the "Mozilla" term that predates the well-known open-source browser  
project by some years.)

> The appName and appVersion attributes are a little better for  
> introducing the OR alternatives but their definitions also must be  
> improved because the first half of each is as meaningless as the above.

This is unlikely to change. As another example of the problem caused,  
Opera was forced to keep its appVersion pegged at 9.8 because common  
sniffing tests couldn't distinguish appVersion = 1 and appVersion = 10.

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

I hope that the reasons I have tried to explain (and which Boris also  
explained, and Karl seemed to assume were well-enough known that he could  
simply point to references) are at least sufficiently objective to be a  
useful explanation of the issues.

> Can we please focus on the purpose and quality of the Navigator object  
> standard and not on any one particular browser agenda? Please.

The *problem* is how to ensure that if you rely on a feature, and it isn't  
present in the user's environment (browser doesn't have it, is turned off,  
the user can't actually use it for example because a speech input API  
doesn't help a person who cannot speak), you can adapt what you do, or at  
least inform the user about the problem.

There are a lot of partial solutions, but I doubt you will find *any*  
browser manufacturer who thinks the Navigator object is a good solution to  
the problem.

cheers

Chaals

> Thanks,
>
> [cid:image001.png@01CF27D9.3440C440]
>
> 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/>
>
>
>
>
> On Tue, Feb 11, 2014 at 11:31 PM, Travis Leithead  
> <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>>  
> wrote:
> Doesn’t this encourage browser detection? I’m sensitive to this topic  
> since IE has been the target of substantial browser detection in the  
> past, and I don’t want to encourage this kind of behavior in the future  
> (for any browser)…
>
> We should also keep in mind that there are other UAs besides browsers…
>
> From: stojadinovicp@gmail.com<mailto:stojadinovicp@gmail.com>  
> [mailto:stojadinovicp@gmail.com<mailto:stojadinovicp@gmail.com>] On  
> Behalf Of Predrag Stojadinovic
> Sent: Tuesday, February 11, 2014 9:06 AM
> To: public-html@w3.org<mailto:public-html@w3.org>
> Subject: Navigator standard change proposal
>
> 1. The current Navigator object standard allows for the appName  
> attribute to be either "Netscape" or the actual name and most major  
> browsers just settle for this default.
> 2. The appVersion attribute is even worse because the definition  
> requires that attribute to either be exactly "4.0", regardless of the  
> actual browser version, OR a detailed string, which is the option that  
> is of course chosen, and is thus cluttered with too much data.
>
> While, on the one hand, this additional data can be useful to some  
> developers, the cluttering, on the other, makes it a nightmare to  
> determine the actual browser and version which the code is being  
> executed in.
> Especially when that data changes from one version to another like we  
> recently had in the IE10 to IE11 upgrade where IE11 all of a sudden was  
> being detected as a special version of Firefox.
> Based on the Navigator  
> object<http://www.w3.org/TR/html5/webappapis.html#the-navigator-object>  
> justification, which states: "This section defines a collection of  
> attributes that can be used to determine, from script, the kind of user  
> agent in use, in order to work around these issues." it is rather  
> surprising that the two, usually most interesting and sought after,  
> pieces of information must be parsed and extracted from too much  
> cluttered text, instead of being readily available on demand.
> Just to be clear, it is certainly better to use Modernizr and similar  
> libraries to determine available features, however, it is up to the  
> developer how they use the information obtained from the navigator  
> object and if they create bad patterns based on the browser name and  
> version than this really is on them. What developers do with this  
> information is ultimately up to them, but if this is what they are  
> actually after then it should be available.
>
> Therefore, since the appName and appVersion have been around for a while  
> and are what they are, instead of changing them, I propose to introduce  
> attributes browserName and browserVersion as following:
>
> readonly attribute DOMString browserName;
> readonly attribute DOMString browserVersion;
>
> window . navigator . browserName
>     Must return the full name of the browser, e.g. "Chrome", "Firefox",  
> "Opera", "Internet Explorer", "Safari", etc.
>
> window . navigator . browserVersion
>     Must return the full version of the browser, e.g. "32.0.1700.107",  
> "27.0", "11.0.9600.16476", "12.11", etc.
>
> Thanks.
>
> Predrag Stojadinović
> NVIDIA Europe, Software Developer
> http://www.nvidia.com
>
>
> 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.
> -----------------------------------------------------------------------------------


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

Received on Wednesday, 12 February 2014 17:16:15 UTC