- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 12 Feb 2014 12:23:14 -0500
- To: public-html@w3.org
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