A quick note about feature detection

The modern web uses two main technologies for determining browser capabilities:
(a) parse the user agent, determine the browser version, and write switches according to the browser version in the code;
(b) try to determine support of features by checking the necessary fields / calls of the necessary methods.

Historically, the second option is considered more true, and it is implemented by all modern projects. Suffice it to say that jQuery follows this path.

And, like, the argumentation is correct: (a) there is no need to keep a regular database, (b) if a new feature appears in some browser, it starts working automatically without changing the code, (c) unknown (exotic, new) browsers will work without additional gestures, (d) if the user has changed the user agent, the code will still work.
')
This is all well and good, but only for small projects.



This approach has intractable difficulties when a particular feature is detected, but does not work.
In an ideal world, if a feature is implemented in the browser, then it works. In real life it can, it works, and maybe not. And in general, a new version of the browser may suddenly break it.

Here transform3d worked for you in Chrome, and then in the 15th version it took and broke:
code.google.
And they fixed it only in the 21st.

How can feature detection help you find out that under some conditions a block with transform3d makes nearby inputs non-clickable?
You can, of course, dodge and write an autotest to the fact that transform3d does not make nearby inputs non-clickable. Over time, your code will turn into a giant autotest for browser bugs.

Or, in Opera 10-11, for the transition to work correctly, you had to call reflow with your hands, pulling an element on the page, otherwise animation artifacts appeared. How does this automatically detect?

In addition to browsers, there is still a giant army of script writers. For example, in the default theme Joomla! 1.5 mootools 1.12 is still used in which the following is written:

Array.extend({ forEach: function (fn,bind) { for (var i=0, j=this.length; i<j; i++) fn.call(bind,this[i],i,this); } }); 

And in the browser implementation the following is written:

 Array.prototype.forEach = function(fn, scope) { for(var i = 0, len = this.length; i < len; ++i) { fn.call(scope || this, this[i], i, this); } } 

Those. the browser implementation with the second parameter not set substitutes the array itself as the context, but the mutuzovskaya one does not. And your beautiful library using feature detection works like a bug in IE in Jumble - because there is a forEach in the prototype array, but it does not work correctly. What to do here? Add feature validation to feature detection or stop using contexts in forEach?

But the good old parsing user-agent from all this saves. Yes, it adds additional work in the definition of working features - but it also eliminates the headache in determining non-working features.

So, if in your project you are intensively using new features of browsers or you are embedded on pages with aggressive user code - feature detection sooner or later will leave you sideways. Yes, parsing a user agent deprives you of a part of the audience with non-standard browsers and redefined user agents — but these are measurable risks. For each non-standard browser, you can look at its share and decide whether its support will pay off. Using the same feature detection adds immeasurable risks to you - the devil knows what proportion of users this or that feature works crookedly.