jQuery upgrades for Infusion (FLUID-5185)

[Antranig Basman]

As expected, a major issue upgrading our core jQuery dependency from its more than year-old status at 1.7.2 
has been the elimination of the jQuery browser detection utility, $.browser. This is used throughout the 
framework and several components, and despite the "popular religion" to the effect that such detections 
should not be used, I think we have enough browser-specific bugs that we require to compensate for that this 
is not feasible in the "real world". Certainly we should commit to a review process to vet each of our 
couple of dozen usages of $.browser(), since many of the bugs that they work around may have been long 
fixed, or appear in browsers outside our support profile - however, this process would unnecessarily slow 
down the release process of Infusion 1.5 and so I believe we must work to restore the $.browser implementation.

Unfortunately the recommended workaround by the jQuery team, the use of the "jQuery Migrate" plugin seems to 
me quite undesirable. For a start, it means taking into the delivered framework image a large amount of code 
(c. 500 lines) most of which we have no use for - since the framework's use of jQuery is generally 
conservative and the whole purpose of this upgrade is to bring it up to date with the latest API - the use 
of a module whose overall purpose is to adapt to obsolete versions of the jQuery API seems perverse. Into 
the bargain, the grip of the "popular religion" on the minds of the jQuery developers lead them to implement 
this library in a noisy way which produces console warnings on any use, and in particular use of the 
$.browser detect which is our only reason for using it.

This warning takes the form of the message "JQMIGRATE: jQuery.browser is deprecated" preceded by a 
exclamation icon and followed by a complete stack trace. This is unreasonably intrusive. In addition, 
adopting this plugin would require an edit to every single HTML demo and test file in the framework image to 
add in the new dependency.

My suggestion for resolving this is to "rip off" an implementation of the small portion of the code that we 
actually require (about 10 lines) into a polyfill in our existing framework file FluidView.js. Another 
possibility is FluidDocument.js, but this latter file contains rarities that are less often included in 
framework tests and demos. Naturally neither choice makes a difference to users of built copies of Infusion 
since both are always included by default.

Please reply with opinions, feedback and alternatives to this proposal -

Cheers,
A