Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)

2012-11-16 Thread Roan Kattouw
On Thu, Nov 8, 2012 at 5:17 PM, Tim Starling tstarl...@wikimedia.org wrote:
 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.

Yes, there are legitimate reasons for using browser detection, in
cases where feature detection doesn't work. The Safari segfault is a
good example. In fact, VisualEditor uses browser detection to disable
itself in browsers with broken contentEditable support, because it's
very hard or impossible to feature-detect this. I believe Timo was
working on cleaning up a different UA detection plugin somewhere on
github and using that for VE's browser detection.

tl;dr: browser detection is evil, you should think twice before using
it, but sometimes you have to

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)

2012-11-16 Thread Krinkle
On Nov 9, 2012, at 2:17 AM, Tim Starling tstarl...@wikimedia.org wrote:

 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
 

jQuery will publish a jquery-compat plugin as they always do when removing 
major features. However I would recommend strongly against using it (at least 
inside MediaWiki) because:

To use it, you'll have to add it to your dependencies. In which case you might 
as well keep your editor open for another minute and use jquery.client instead.

And, the old jQuery.browser was pretty basic anyway:
https://github.com/jquery/jquery/blob/1.8.3/src/deprecated.js#L12

But if you're working outside MediaWiki and need it is good enough for you, 
you'd copy and paste those dozen or so lines. Or (after jQuery 1.9 is released) 
simply load the jquery-compat version on your web page.

-- Krinkle


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)

2012-11-08 Thread Jérémie Roquet
Hi Timo,

2012/11/7 Krinkle krinklem...@gmail.com:
 Just a reminder that jQuery will (after almost 4 years of deprecation!) drop
 $.browser [1] in jQuery 1.9.

Thanks for the reminder: it was still used in the MediaWiki:Commons.js
of the French Wikipedia.
What frightens me a bit is that I've been unable to find it using the
internal MediaWiki search engine; I've had to search by myself.

Best regards,

-- 
Jérémie

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)

2012-11-08 Thread Tim Starling
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


Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)

2012-11-07 Thread .
On 7 November 2012 03:09, Krinkle krinklem...@gmail.com wrote:
..
 == Feature detection

 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.

 Research on the internet and look for a way to detect this properly (examples
 below). Browser detection (instead of feature detection) is not reliable, nor 
 is
 it very effective. For example, Internet Explorer has changed a lot since IE6.
 Blindly doing A for IE and B for non-IE isn't very useful anymore as most (if
 not all) of the new features will work fine in IE8, IE9 or IE10.

The other day I detected that IE don't support deleting  option
elements from inside a optgroup.  The element is removed from the
DOM, but is still visible on the webpage ( Yes, the DOM and the
webpage become unsynced: you see elements that don't really exist). I
have googled this, and nobody has find this bug (maybe nobody is using
optgroup in a DHTML way before, or is doing under a closed door, not
public. Or people avoid advanced features, to avoid IE bugs ).  I
can't imagine the pain of the creators of something like Google Docs.
And If Google, with all his money and resources, talented workers and
influence, can't support IE7   [1], ... What I can do?

I suppose the fix will come close, with a plugin that will add again
the feature.




[1]
http://googleenterprise.blogspot.com.es/2011/06/our-plans-to-support-modern-browsers.html



--
--
ℱin del ℳensaje.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l