Re: Navigator standard change proposal

On 2/12/14 12:06 PM, Predrag Stojadinovic wrote:
> - So, it is up to the standard to prevent the users from misusing it?

It is up to the standard to provide ways of addressing use cases that 
will be used correctly more often than not.

A standard that everyone routinely misuses has failed.

> As I explained already, how the developers use the information provided is
> on them.

While true, creating APIs that are hard to impossible to use well is a 
failure of the standards body (or whoever the API designer is), not of 
the developers who then proceed to use the API badly.

Sometimes there are overriding considerations that make such an API 
necessary.  But if there are not, it's better to create APIs that do the 
right thing when used in the naive way than to create APIs that do the 
wrong thing when thus used.

> My proposal deals with the simple fact that the Navigator
> object does not do what it is supposed to do

I think you're presupposing what it's supposed to do.

> that is to provide the
> information about the browser and engine used.

This is where we disagree.  Providing such information is an anti-goal.

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

The problem with the mobile UA detection is not a failure in the 
_parsing_.  It's a failure in the interpretation of the resulting 
tokens.  Simply exposing those tokens on Navigator would not make things 
any better.

> And why did UA sniffing come about? Because the appName and appVersion
> were poorly defined and thus unusable.

The problem with UA sniffing is not that it can't reliably extract the 
kind of browser and its version; in fact it can.

The problem is that people then routinely misuse that information.

> So, the question is, should the Navigator object be properly defined to
> eliminate the need for UA sniffing or not?

I think your definition of "UA sniffing" as "Parse the UA string" is 
incorrect.  "UA sniffing" is any time you assume something about an 
engine based on some other bit of information or meta-information about 
the engine.  For example, if you assume that only browsers with an 
appName of "Firefox" have a certain API, you're doing UA sniffing.  If 
you assume that browsers with an appName of "Firefox" _don't_ have a 
certain API you are also doing UA sniffig.  If you assume that the set 
of browsers which support the "-webkit-animation" CSS property is 
identical to the set of browsers that support CSS Transitions, that is 
likewise UA sniffing...

On the other hand, if you assume that browsers that support the 
"transition" CSS property also support CSS Transitions that's not UA 
sniffing: that's capability detection.  This is the preferred method to 
use for detecting what a UA is capable of.

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

It sure sounded to me like you were.

Maybe you're arguing that it's better but UA sniffing should not be 
deprecated anyway?  That's where we disagree then: UA sniffing is so 
broken in practice that we should do everything we can to discourage it.

> The feature detection is not the issue, the issue is the Navigator
> object, it’s purpose and definition.

Its purpose is to make old broken pages that use UA sniffing continue to 
work.

> 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 something we may have to agree to disagree on.  This does mean 
browsers have to not provide reasons for developers to want to know this 
information, of course.

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

We should tighten up the definition by requiring a fixed appName, etc, I 
agree.

-Boris

Received on Wednesday, 12 February 2014 17:23:54 UTC