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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l