That was an animated page transition effect to a page that we added with a data-transition attribute on the link. This uses a different background theme swatch to see how that looks with the transitions.
Since it uses CSS animations, this should be hardware accelerated on many devices. To see transitions, 3D transform support is required so if you only saw a fade transition that's the reason.
That was an animated page transition effect to a dialog that we added with a data-transition attribute on the link.
Since it uses CSS animations, this should be hardware accelerated on many devices. To see transitions, 3D transform support is required so if you only saw a fade transition that's the reason.
The jQuery Mobile framework includes a set of CSS-based transition effects that can be applied to any page link or form submission with Ajax navigation.
Important: Some platforms currently have issues with transitions. We are working on a solution to solve the problem for everyone. If you are experiencing flickers and flashes during or at the end of a transition we suggest the following workaround. Please note that this workaround should be thoroughly tested on the target platform before deployment. This workaround is known to cause performance issues and browser crashes on some platforms, especially Android. Add the following code to your custom css:
.ui-page { -webkit-backface-visibility: hidden; }
Only seeing fade transitions? To view all transition types, you must be on a browser that supports 3D transforms. By default, devices that lack 3D support (such as Android 2.x) will fallback to "fade" for all transition types. This behavior is configurable (see below).
Transitions were originally inspired by jQtouch They've since been rebuilt, but props to David Kaneda and Jonathan Stark for the initial guidance.
Setting a transition
By default, the framework applies a fade transition. To set a custom transition effect, add the data-transition attribute to the link.
When the Back button is pressed, the framework will automatically apply the reverse version of the transition that was used to show the page. To specify that the reverse version of a transition should be used, add the data-direction="reverse" attribute to a link.
Global configuration
Set the defaultPageTransition global option if you'd prefer a different default transition. Dialogs have a different option called defaultDialogTransition that can also be configured.
Browser support
All transitions are built with CSS keyframe animations and include -webkit vendor prefixed rules for iOS, Blackberry, Android, Safari and Chrome browsers, -moz rules for Firefox browsers, and unprefixed rules for Windows Phone 8 and IE10. Support for keyframe animations and transition smoothness is determined by the browser version and hardware and will safely fall back to no transition if animations aren't supported. To proactively exclude transition in situations with poor performance, we exclude browsers that lack 3D transforms and provide a fallback transition and apply a max width for when transitions are applied.
Fallback transition
By default, all transitions except fade require 3D transform support. Devices that lack 3D support will fall back to a fade transition, regardless of the transition specified. We do this to proactively exclude poorly-performing platforms like Android 2.x from advanced transitions and ensure they still have a smooth experience. Note that there are platforms such as Android 3.0 that technically support 3D transforms, but still have poor animation performance so this won't guarantee that every browser will be 100% flicker-free but we try to target this responsibly.
The fallback transition for browsers that don't support 3D transforms can be configured for each transition type, but by default we specify "fade" as the fallback. For example, this will set the fallback transition for the slideout transition to "none":
$.mobile.transitionFallbacks.slideout = "none"
Max scroll for transitions
By default, transitions are disabled (set to "none") when you're either coming FROM or going TO a page where the scroll position is 3x the height of the device's screen.
This feature was added because of the slow response times and the possibility of browser crashing when clicking on a list item (or any navigation element) far down a long page which leads to the
browser trying to animate a really massively tall page from the scroll position to the top of the screen. The scroll position, not total screen height, is the determining factor for performance.
This scroll position breakpoint is configurable via the new getMaxScrollForTransition function.
Max width for transitions
By default, transitions can be disabled (set to "none") when the window width is greater than a certain pixel width. This feature is useful because transitions can be distracting or perform poorly on larger screens. This value is configurable via the global option $.mobile.maxTransitionWidth, which defaults to false. The option accepts any number representing a pixel width or false value. If it's not false, the handler will use a "none" transition when the window is wider than the specified value.
Same page transition
Transitions to the current active page are ignored by default but can be enabled by using the allowSamePageTransition option of the pagecontainer widget's change() method. Note that not all transitions will work as expected and may end in an impractical result.
Creating custom transitions
jQuery Mobile allows for the addition of custom transitions to the $.mobile.transitionHandlers dictionary so you can expand the selection of transitions on your site or app.
The toolbar widget is used to enhance headers and footers.
Markup
Header
The header is a toolbar at the top of the page that usually contains the page title text and optional buttons positioned to the left and/or right of the title for navigation or actions.
The title text is normally an H1 heading element but it's possible to use any heading level (H1-H6) to allow for semantic flexibility. The framework add class ui-title to headings that are immediate children of toolbars. All heading levels with class ui-title are styled identically by default to maintain visual consistency.
Page Title
Footer
The footer is a toolbar at the bottom of the page that can contain a wide range of content, from form elements to navbars.
The footer bar has the same basic structure as the header except it uses the data-role attribute value of footer. Headings that are immediate children of the footer get class ui-title, just like headers.
Powered by jQuery Mobile
Theme
The header and footer toolbar inherit the theme swatch from the page by default but you can easily set the theme swatch color. If you use external fixed toolbars you always have to set a theme, because there is no parent page from which they can inherit the theme.
Page Title
External toolbars
If you want to use the same toolbar on multiple pages, you can use external toolbars.
Fixed position
Toolbars can be set to fixed position by adding the data-position="fixed" to the header or footer. This will make them remain at the top (header) or bottom (footer) of the window at all time instead of scrolling with the page. See fixed toolbars.
Fullscreen position
The toolbars can be set to fullscreen fixed position that overlays the toolbar over the content by adding the data-fullscreen="true" to a fixed header. See fullscreen toolbars.
The framework automatically enhances links in toolbars as buttons with inline and mini style, but this has been deprecated in version 1.4. The same goes for positioning the first two buttons in a header left and right if they are immediate child of the header. The demos below prepare you for the next version.
Header button position classes
You can use the ui-btn-left and ui-btn-right classes to position buttons in the header.
The heading in the header bar has some margin that will give the bar its height. If you choose not to use a heading, you will need to add an element with class="ui-title" so that the bar can get the height and display correctly.
The classes ui-btn-left and ui-btn-right were not meant to be used in footers, because they do not account for the possible presence of text, navbars, and and other elements often present in footers. You can nevertheless achieve a similar effect when you add a bit of custom CSS.
jQuery Mobile has a feature to automatically create and append "back" buttons to any header, though it is disabled by default. This is primarily useful in chromeless installed applications, such as those running in a native app webview. The framework automatically generates a "back" button on a header when the page plugin's addBackBtn option is true. This can also be set via markup if the header has a data-add-back-btn="true" attribute.
If you use the attribute data-rel="back" on an anchor, any clicks on that anchor will mimic the back button, going back one history entry and ignoring the anchor's default href. This is particularly useful when linking back to a named page, such as a link that says "home", or when generating "back" buttons with JavaScript, such as a button to close a dialog. When using this feature in your source markup, be sure to provide a meaningful href that actually points to the URL of the referring page. This will allow the feature to work for users in C-Grade browsers.
If you just want a reverse transition without actually going back in history, you should use the data-direction="reverse" attribute.
Customizing the back button text
If you'd like to configure the back button text, you can either use the data-back-btn-text="previous" attribute on your header element, or set it programmatically via the toolbar plugin's options: $.mobile.toolbar.prototype.options.backBtnText = "previous";
Default back button style
If you'd like to configure the back button theme, you can use: $.mobile.toolbar.prototype.options.backBtnTheme = "a";
If you're doing this programmatically, set this option inside the mobileinit event handler.
Navbars
See navbar for examples of navigation bars inside toolbars.
Grouped buttons
To group buttons into a button set, wrap the links in an element with data-role="controlgroup" and data-type="horizontal" attributes.
By default, toolbars don't have any padding to accommodate nav bars and other widgets. To add padding inside of a full-width toolbar, wrap the toolbar's contents in an element and add class ui-bar to that element or apply your own padding rule in your custom CSS.
In browsers that support CSS position: fixed (most desktop browsers, iOS5+, Android 2.2+, and others), toolbars that use the "fixedtoolbar" plugin will be fixed to the top or bottom of the viewport, while the page content scrolls freely in between. In browsers that don't support fixed positioning, the toolbars will remain positioned in flow, at the top or bottom of the page.
Fixed basics
To enable this behavior on a header or footer, add the data-position="fixed" attribute to a jQuery Mobile header or footer element.
Fullscreen fixed toolbars sit on top of the content at all times when they are visible, and unlike regular fixed toolbars, fullscreen toolbars do not fall back to static positioning when toggled. Instead they disappear from the screen entirely. Fullscreen toolbars are ideal for more immersive interfaces, like a photo viewer that is meant to fill the entire screen with the photo itself and no distractions.
To enable this option on a fixed header or footer, add the data-fullscreen attribute to the element.
While all form elements are now tested to work correctly within static toolbars as of jQuery Mobile 1.1, we recommend extensive testing when using form elements within fixed toolbars or within any position: fixed elements. This can potentially trigger a number of unpredictable issues in various mobile browsers, Android 2.2/2.3 in particular (detailed in Known issues in Android 2.2/2.3, below).
Prior to version 1.1, jQuery Mobile used dynamically re-positioned toolbars for the fixed header effect because very few mobile browsers supported the position:fixed CSS property, and simulating fixed support through the use of "fake" JavaScript overflow-scrolling behavior would have reduced our browser support reach, in addition to feeling unnatural on certain platforms. This behavior was not ideal, and jQuery Mobile 1.1 took a new approach to fixed toolbars that allows much broader support. The framework now offers true fixed toolbars on many popular platforms, while gracefully degrading non-supporting platforms to static positioning.
Polyfilling older platforms
The fixed toolbar plugin degrades gracefully in platforms that do not support CSS position:fixed properly, such as iOS4.3. If you still need to support fixed toolbars on that platform (with the show/hide behavior) included in previous releases, Filament Group has developed a polyfill that you can use.
Just include the CSS and JS files after your references to jQuery Mobile and Fixed toolbars will work similarly to jQuery Mobile 1.0 in iOS4.3, with the inclusion of the new API for the 1.1 fixedtoolbar plugin.
If you have any improvements to suggest, fork the gist on github and let us know!
Known issue with form controls inside fixed toolbars, and programmatic scroll
An obscure issue exists in iOS5 and some Android platforms where form controls placed inside fixed-positioned containers can lose their hit area when the window is programatically scrolled (using window.scrollTo for example). This is not an issue specific to jQuery Mobile, but because of it, we recommend not programatically scrolling a document when using form controls inside jQuery Mobile fixed toolbars. This ticket from the Device Bugs project tracker explains this problem in more detail.
Known issues in Android 2.2/2.3
Android 2.2/2.3's implementation of position: fixed; can, in conjunction with seemingly unrelated styles and markup patterns, cause a number of strange issues, particularly in the case of position: absolute elements inside of position: fixed elements. While we've done our best to work around a number of these unique bugs within the scope of the library, custom styles may cause a number of issues.
Form elements elsewhere on the page—select menus in particular—can fail to respond to user interaction when an empty absolute positioned element is placed within a fixed position element. In rare cases—and specific to Android 2.2—this can cause entire pages to fail to respond to user interaction. This can seemingly be solved by adding any character to the absolute positioned element, including a non-breaking space, and in some cases even whitespace.
The above-described issue can also be triggered by an absolute positioned image inside of a fixed position element, but only when that image is using something other than its inherent dimensions. If a height or width is specified on the image using CSS, or the image src is invalid (thus having no inherent height and width), this issue can occur. If an image that is inherently, say, 50x50 pixels is placed in a fixed element and left at its inherent dimensions, this issue does not seem to occur.
When a position: fixed element appears anywhere on a page, most 2D CSS transforms will fail. Oddly, only translate transforms seem unaffected by this. Even more oddly, this issue is solved by setting a CSS opacity of .9 or below on the parent of the fixed element.
Combinations of position: fixed and overflow properties are best avoided, as both have been known to cause unpredictable issues in older versions of Android OS.
Any element that triggers the on-screen keyboard, when placed inside a position: fixed element, will fail to respond to user input when using anything other than the default keyboard. This includes Swype, XT9 or, it seems, any input method apart from the standard non-predictive keyboard.
While we will continue to try to find ways to mitigate these bugs as best we can, we currently advise against implementing fixed toolbars containing complicated user styles and form elements without extensive testing in all versions of Android's native browser.
No longer supported: touchOverflowEnabled
Prior to jQuery Mobile 1.1, true fixed toolbar support was contingent on native browser support for the CSS property overflow-scrolling: touch, which is currently only supported in iOS5. As of version 1.1, jQuery Mobile no longer uses this CSS property at all. We've removed all internal usage of this property in the framework, but we've left it defined globally on the $.mobile object to reduce the risk that its removal will cause trouble with existing applications. This property is flagged for removal, so please update your code to no longer use it. The support test for this property, however, remains defined under $.support and we have no plans to remove that test at this time.
These pages are a demo of a persistent navbar in a fixed footer toolbar. Click on any of the links in the footer, and you'll see the page content transition. Both the persistent header and footer on these pages remain in place during the animation to a new HTML page.
With the new external toolbars no extra effort is required to now have persistent toolbars. Simply place them outside of the page container on each page they will be loaded on the first page and persist on subsequent pages. The toolbars still need to be placed on each page to account for refresh however they will be ignored if not within a page container.
Typically, the persistent toolbar technique will be combined with fixed positioning.
Updating toolbar contents
Because the same toolbar is used on every page, you might want to update the content. In this demo we show how to change the heading in the header and set the nav button of the page currently in view to the active state.
Improving page load with persistent toolbars
By combining this technique with a little bit of server side logic you can reduce the file size for each page load significantly by not sending anything except the actual page container back when the request is from ajax. this not only reduces file size but makes the actual processing of the page quicker also. To see an example of this technique see Ajax optimized persistent toolbars
A note about transitions
By Removing the toolbars from the page container they are no longer part of the page transition which dramaticly improves the performance of complex 3D page transitions over the older style of persistent toolbars.
These pages have been optimized on the server side to check if the request is coming from an Ajax request and if so they only send the actual page div instead fo the entire page. If you navigate to any of the pages in the nav bar at the bottom and inspect the return data you will see it contains no head, toolbars, html tag, or body tag.
However if you refresh the page all of these things will be present. This is done by checking the HTTP_X_REQUESTED_WITH header
if (!isset($_SERVER['HTTP_X_REQUESTED_WITH']) || strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) !== 'xmlhttprequest') {
All of the markup not needed when being requested via Ajax is wrapped in if statements like the one above.
This page demonstrates the "fullscreen" toolbar mode. This toolbar treatment is used in special cases where you want the content to fill the whole screen, and you want the header and footer toolbars to appear and disappear when the page is clicked responsively — a common scenario for photo, image or video viewers.
To enable this toolbar feature type, you apply the data-fullscreen="true" attribute and the data-position="fixed" attribute to both the header and footer div elements. The framework will also unset the padding for the content container (.ui-content).
Keep in mind that the toolbars in this mode will sit over page content, so not all content will be accessible with the toolbars visible.
Since external toolbars are outside the page they don't inherit a theme from the page. This means you always have to set a theme for them. You can use the data-theme attribute for this or set the theme option when you call the plugin:
$(function(){
$( "[data-role='header'], [data-role='footer']" ).toolbar({ theme: "a" });
});
True persistent toolbars
Because External toolbars are outside of the page they are not effected by transition and make truly persistent toolbars possible.
The header and footer on this page are positioned outside the page. They are before and after the page within the body. These Toolbars will remain in the dom until manually removed.
Markup
The markup for external toolbars is identical to normal toolbars, you just place the toolbar outside the page within the body of your page
Auto init
Because these toolbars are not within the page they will not auto initalize. You must call the toolbar plugin yourself.
Since external toolbars are outside the page they don't inherit a theme from the page. This means you always have to set a theme for them. You can use the data-theme attribute for this or set the theme option when you call the plugin:
$(function(){
$( "[data-role='header']" ).toolbar({ theme: "a" });
});
Ajax navigation
Because these toolbars are not within the page they will remain in the DOM until manually removed.
Toolbars not within a page will not be pulled into the DOM during Ajax navigation.
Fixed external toolbars
External toolbars can also be set to fixed positioning just like normal toolbars: External fixed toolbars
click on the button to dynamically inject toolbars. Note that we have to update the page height and padding by calling $.mobile.resetActivePageHeight();.
This "classic" theme mimics the old jQuery Mobile default theme. IMPORTANT: This classic theme is only a demo and not a supported feature. Issues or ThemeRoller incompatibility might not be fixed, this theme is not available on the CDN, and this demo can be removed at any time.