jQuery upgrades for Infusion (FLUID-5185)

Justin Obara obara.justin at gmail.com
Wed Dec 18 13:33:01 UTC 2013

Thanks for looking into this. I could be wrong, but I believe the reason, or one of the reasons, for the migrate plugin is to assist in moving away from jQuery's old API. This would be why there are so many console logs. So, I agree, we probably shouldn't distribute this file. 

For our future 2.0 release, I'd like to try to evaluate all of the work arounds in our code. I'm hoping that we'll be able to jettison a number of these for the case you mentioned (e.g. browser support, resolved bugs, and etc.), which would also help improve performance and lean out our code too. 

In the 1.5 scope, would it be possible to move these checks into the progressive enhancement code?

On Dec 18, 2013, at 3:03 AM, Antranig Basman <Antranig.Basman at colorado.edu> wrote:

> 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
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

More information about the fluid-work mailing list