I have roughly translated some of the articles, may have misunderstood the place, please correct me. It is worth mentioning that the debate in the comments section is also worth seeing.
Feature Detection
At first, the front-end engineers objected to browser testing, which they thought was bad because it was not a future-oriented code and could not adapt to new browsers. A better approach is to use feature detection, just like this:
Copy Code code as follows:
if (Navigator.userAgent.indexOf ("MSIE 7") >-1) {
Do something
}
And the better way to do this is to:
Copy Code code as follows:
if (document.all) {
Do something
}
The two methods are not the same. The former is the special name and version of the browser, which detects the browser's characteristics. UA sniffing can pinpoint the type and version of the browser (at least the browser type), while feature detection is to determine whether the browser owns an object or supports a method. Notice that the two are completely different.
Because feature detection relies on which browsers are supported, tedious validation is required when a new version of the browser appears. For example, when the DOM standard first appeared, not all browsers supported the getElementById () method, so the first code might be like this:
Copy Code code as follows:
if (document.getElementById) {//dom
element = document.getElementById (ID);
else if (document.all) {//ie
element = Document.all[id];
else if (document.layers) {//netscape < 6
element = Document.layers[id];
}
This is a good example of feature detection, and the bright spot is that you don't have to modify the code when other browsers start supporting the getElementById () method.
Blending mode
Then the front-end engineers consider the improvement of the wording, the code changes like this:
Copy Code code as follows:
Avoid!!!
if (document.all) {//ie
id = Document.uniqueid;
} else {
id = math.random ();
}
The problem with this code is to determine if it is IE by detecting the document.all property. When IE is determined, it is also safe to assume that the private Document.uniqueid property is used. However, what is currently done is to determine whether to support document.all, not to identify whether the browser is ie. Simply supporting document.all does not mean that Document.uniqueid is available.
Then people began to write this, using the following line instead of the above:
var Isie = navigator.userAgent.indexOf ("MSIE") >-1;
The following line replaces the line above.
var Isie =!! Document.all These changes indicate that there is a misunderstanding of "don't use UA sniffing"--no longer detecting the details of the browser, instead of using feature support to infer it. This is a very bad way to detect based on browser features.
Later, the front end found that document.all is not reliable, better detection of IE into:
var Isie =!! document.all && Document.uniqueid; This way of implementation is misguided. Not only does it take time and effort to identify the added feature support of browsers, it is also not certain that other browsers are starting to support the same features.
If you think such code is not widely used, look at the old version of the MooTools code snippet:
Copy Code code as follows:
From MooTools 1.1.2
if (window. ActiveXObject) window.ie = Window[window. XMLHttpRequest? ' IE7 ': ' IE6 '] = true;
else if (document.childnodes &&!document.all &&!navigator.taintenabled) Window.webkit = window[ Window.xpath? ' webkit420 ': ' webkit419 '] = true;
else if (document.getboxobjectfor!= null | | | Window.mozinnerscreenx!= NULL) Window.gecko = true;
Notice how it is used for feature detection. I can point out a series of problems, such as detecting window.ie will mistake IE8 for IE7.
Aftermath
With the rapid development of browsers, the use of feature detection has become increasingly difficult and unreliable. However, MooTools 1.2.4 still uses this method, for example: Getboxobjectfor ().
Copy Code code as follows:
From MooTools 1.2.4
var Browser = $merge ({
Engine: {name: ' Unknown ', version:0},
Platform: {name: (window.orientation!= undefined)? ' ipod ': (Navigator.platform.match (/mac|win|linux/i) | | [' Other ']) [0].tolowercase ()},
Features: {xpath:!! (document.evaluate), air:!! (window.runtime), query:!! (Document.queryselector)},
Plugins: {},
Engines: {
Presto:function () {
Return (!window.opera)? False: ((Arguments.callee.caller) 960: ((document.getelementsbyclassname)? 950:925));
},
Trident:function () {
Return (!window. ActiveXObject)? False: (window. XMLHttpRequest)? ((document.queryselectorall)? 6:5): 4);
},
Webkit:function () {
Return (navigator.taintenabled)? False: ((Browser.Features.xpath)? ((Browser.Features.query)? 525:420): 419);
},
Gecko:function () {
Return (!document.getboxobjectfor && Window.mozinnerscreenx = null)? False: ((document.getelementsbyclassname) 19:18);
}
}
}, Browser | | {});
What should I do?
Feature detection is a method that should be avoided, although direct feature detection is a good way to meet requirements in most cases. It is generally only possible to know whether this feature is implemented before testing, and not to consider the relationship between them.
I'm not saying that you never use browser feature detection but based on UA sniffing because I believe it has a lot of uses, but I don't believe it has a lot of reasonable uses. If you're thinking about UA sniffing, follow this idea: The only safe way to do this is to target specific versions of a particular browser that are unreliable beyond the scope-for example, a new browser version. This is also a sensible way to do this, because backward compatibility with older versions is the simplest approach compared to newer versions of forward-compatible uncertainties.
