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

Reply via email to