On 07/11/12 13:09, Krinkle wrote:
In most (if not all) cases of people using $.browser it is because they want different behaviour for browsers that don't support a certain something. Please take a minute to look at the code and find out what it is you are special-casing for that apparently doesn't work in a certain browser.
In OggHandler we used browser detection for several things. It is not affected by this change because it never used jQuery, but I would still be interested to know how such code could possibly be migrated to feature detection.
For example:
if ( this.safari ) { // Detect https://bugs.webkit.org/show_bug.cgi?id=25575 var match = /AppleWebKit/([0-9]+)/.exec( navigator.userAgent ); if ( match && parseInt( match[1] ) < 531 ) { this.safariControlsBug = true; } }
...
if ( !this.safariControlsBug ) { html += ' controls'; }
The issue is that if you use the "controls" attribute in Safari before version 531, it segfaults. Last time I checked, JavaScript didn't have the ability to generate different attributes depending on whether or not its host segfaults.
I can understand the rationale behind removing jQuery.browser: apparently most developers are too stupid to be trusted with it. Maybe the idea is to use per-project reimplementation of jQuery.browser as an intelligence test. The trouble is, I think even the stupidest developers are able to copy and paste.
-- Tim Starling