…overflow-scrolling: touch. True fixed headers and footers come supported as well.
… plugin file. Fixes #2123
…an be used ad-hoc. - Internally, each plugin self-initializes by binding to the pagecreate event. - Unit tests have been added and adjusted to support some internal changes involved in this commit. - In the process, the portions of the page plugin that were used to enhance the header,content,and footer sections of a native-app style page layout are now located in jquery.mobile.page.sections.js. - No public API options have changed, except that the page plugin no longer has options for keepNative, and degradeInputs, as plugins now handle these internally (keepNative was never documented, and degradeInputs only affected slider, so it lives there now. Page options related to the page sections are now located in the page.sections script, but they are still configurable via the page plugin's options api. - Make, Ant, and index files are updated with a new load order for all JS files.
…/latest build. Fix output name for the same
…r make process so the user knows whats going on
…l have the git info used for that build. Deploy will still use the version in the version.txt file
… custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute. 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.
…t doesnt go into a sub folder
…enu without it. Removes off about 3-4kb after minify.
…nclude thems/default. This should fix Opera Mobile Issue 763.
…odel related scripting into jquery.mobile.navigation.js. This includes event handling for click, submit, and hashchange, all of the base tag management, path management, active link class handling, etc. All existing core tests are passing, and all demos work as expected. More tests are needed in core, and this refactor should make those tests easier to write.