jQuery upgrades for Infusion (FLUID-5185)
antranig.basman at colorado.edu
Wed Dec 18 08:03:00 UTC 2013
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 -
More information about the fluid-work