* whitespace within parenthesis
* double quotes
* line breaking for object key assignments
Also made several changes suggested by jsHint.
All tests pass as before -- still failing first three tests as before.
Signed-off-by: Steven Black <steveb@stevenblack.com>
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
Removed the return false in the vclick handler of collapsible and replaced it with a preventDefault(). The only reason we were returning false was to stopPropagation() so that the vclick handler in navigation.js didn't place a ui-btn-active on it.
- Check for existence of the bindings object before attempting to use it. Apparently jQuery core strips off any data bindings of an element before calling teardown on it to remove special event handlers.
- When we switched to virtual mouse events, I just did a straight translation of the code that existed which basically did the collapse/expand on mouseup. In order to factor in scrolling, I needed to move that code into a vclick handler and stopPropagation() and preventDefault() to make sure the button doesn't activate.
- algorithmic optimization of listview.filter
- functional optimization by supporting data-filtertext attribute
includes patch from mathieucarbou: f58631d07d
- Modified vmouse code so that it uses $.data() instead of $().data() which is significantly faster.
- Modified the navigation and buttonMarkup code so they stop using live(). The vmouse code triggers several events during the touch events, which in turn causes the underlying event code to call $.closest() with the selector used during the live() call to figure out if the event should be handled. This turns out to be very expensive, so instead, we now just bind directly to the document, and walk the DOM manually to figure out if we should handle it. This is much faster since we are avoid triggering multiple nested function calls.
Needed to modify _itemApply() to look for the first image that is the first child of its parent. I may need to tweak this at a later point because the selector is still too general.
- Don't bind and unbind our touch listeners dynamically. This gets Android 2.1 into a strange state where it stops dispatching touch events. Instead, we now register our touchmove, touchend and scroll listeners at the same time we register our permanent touchstart listener, we then block and unblock processing in our touch listeners via a flag.
- Some optimizations to speed things up:
- Modified _itemApply() to make use of item.children() and filters. Also got rid of some unused code.
- Convert .each() in refresh() to a loop.
- Cache some $list.jqmData() values so we don't do it for each list item.
1333 - Delay when scrolling over list when data-theme="d"
1368 - Listview refresh performance on a4
1407 - Bad scroll performance since A4 on iPhone 3G
Removed the checking for window.pageX/pageY in the vmouse touch callbacks. Accessing pageX/pageY causes the browser to flush its rendering queue.
- set active state on all button vclick events
- cancelled vclick on slider switch handles so it's not too sticky.
- removed addClass in navigation.js as the first change handles it there.
- Modified createVirtualEvent to use changedTouches if touches doesn't exist.
- Also filed issue 1373 about the fact that we really need to be tracking touch identifiers in the vmouse code.
- Third party click handlers never called.
- Touch and click target mismatches due markup changes before the click events are generated. (What looks like a double click event)
For vclicks dispatched via touchend, calling preventDefault causes mouse clicks to be suppressed. This is why the 3rd party onclick handlers weren't getting triggered. For vclicks dispatched by a real mouse click this isn't a problem.
The fix basically removes the preventDefault() call from the live("vclick") handler and places it in a real live("click") handler. This allows the mouse event to get dispatched and trigger 3rd party click handlers, and still call preventDefault to prevent the link from being followed.
