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? Thanks Justin On Dec 18, 2013, at 3:03 AM, Antranig Basman <[email protected]> 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 - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
