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
