Closed loganfranken closed 12 years ago
Logan,
These should clear up your questions:
document
and not window
. That's probably the easiest fix there. For one reason or another, we elected not to use plugin initialization itself, but maybe that works.Would you like to take a pass at this or should we queue it up? The fix should be to MWF 1.2 branch and then we'll port it over to MWF 1.3.
Thanks Eric! I'll put together the fix a little later today.
Thanks Logan. Assigning this over to you then.
Note that there are two places in the framework where document.addEventListener('load',...)
is called where window.addEventListener('load',...)
is meant. The first is in the jquery swipe stuff. The second is in preview_menu.src.js/preview_menu.js.
Since it was such a trivial change, I went ahead and pulled in the change from my repo. I hope that was alright (but let me know if it wasn't!)
You can push/pull for exactly that reason :) Thank you!
On May 13, 2012, at 6:03 PM, "Logan Franken" reply@reply.github.com wrote:
Since it was such a trivial change, I went ahead and pulled in the change from my repo. I hope that was alright (but let me know if it wasn't!)
Reply to this email directly or view it on GitHub: https://github.com/ucla/mwf/issues/143#issuecomment-5681057
I realize that the current Touch Transitions library (https://github.com/ucla/mwf/wiki/API%3A-JS%3A-Touch-Transitions) is in flux, but it appears that the code for the jQuery plug-in (jSwipe) used by the transitions library is wrapped in a
document.addEventListener('load', function() { })
, which will never get called because theload
event on thedocument
object is deprecated in most browsers (http://my.opera.com/hallvors/blog/2009/05/20/the-day-supporting-document-onload-became-a-bug).Seems like the easiest fix would be to just remove
addEventListener
and let the plug-in initialize itself as soon as it gets imported to the page. I can put together the fix, but I was just wondering: