The Future of jQuery UI and jQuery Mobile

Posted on by

Reposted from

The last few years have been difficult for the jQuery UI and jQuery Mobile projects. The projects have suffered from lack of resources and funding and loss of contributors due to a variety of factors. These combined factors have nearly stopped development on both projects. To remedy this situation we have decided to make some changes in the projects’ teams in addition to how they work.

Scott Gonzalez has lead the jQuery UI project for many years now and has helped to improve the quality tremendously. He has decided to step down from leading the project though he will still be helping in various ways. In an attempt to best utilize resources we have decided to combine the 2 teams into a single team under the leadership of Alex Schmitz, a long time jQuery UI contributor as well as the lead for jQuery Mobile. What this means is that the combined contributors will be able to serve the projects better, since both projects are very tightly coupled as jQuery Mobile depends upon jQuery UI. This does not mean that the two projects will become a single project. Both projects will continue to exist in their own repositories. However, we do hope to continue reducing the amount of duplicated code and widgets in the projects moving anything common to jQuery UI. Eventually, making jQuery Mobile more of an app framework with all the widgets living in jQuery UI.

In the past, when someone wanted to join the jQuery UI or jQuery Mobile teams we expected them to contribute to the library as a whole. We think going forward this needs to change; we will now be looking for and accepting people that are just interested in maintaining a single piece of the library, requiring a much smaller time contribution. So, if someone is just interested in working on sortable they could just lead the sortable widget without having to contribute to any other parts of the two libraries. This will not only allow for more focused and less time consuming contribution but also allow better specialization within our team.

In the past we have done all communication through IRC. Over time however, we have seen a large decrease in the number of people on IRC while other projects have had great results with easier to use tools like Slack. As a result, we will be switching to Slack for daily communication and meetings. We hope that this will ease contributions and interactions with potential new team members. Anyone can join the new Slack channel by navigating to (Update: jQuery Chat).

In conclusion, we are currently very interested in attracting new team members to the combined jQuery UI and jQuery Mobile team. Anyone who is interested can feel free to reach out to Alex Schmitz, the new team lead for both projects, join our slack channel or even find us on IRC (we are still there). jQuery UI and jQuery Mobile rely on contributions from the community and can only continue to exist with your help!

JQuery Mobile 1.5.0-alpha.1 Released

Posted on by

The first alpha release for jQuery Mobile 1.5 is out with numerous bug fixes, an updated base theme, overhauled auto initialization, new methods,  and new widgets!

The big changes:

  • New widgets: we have adopted the new controlgroupcheckboxradio, and button widgets from jQuery UI and have incorporated the accordion widget to replace the collapsible and collapsible set widgets which have been deprecated.
  • Rewritten widgets: The navbar and table widgets have been re-written with new features, performance improvements, and modularization improvements.
  • New auto enhancement module: The auto init for jquery mobile has been extracted into its own general purpose module with speed improvements that can make it faster then calling individually. On
  • Improved modularization: All code is now fully modularized to be able to include just the code you need.
  • Backcompat module: We now include all backcompat code as separate modules so it can be excluded and include a method to turn off all backcompat code for testing and upgrade.
  • New method: The .labels() method finds all label elements associated with the first selected element, mimicking the native labels property and has been incorporated from jQuery UI.
  • npm support: The jquery-mobile package on npm is now owned and maintained by the jQuery Mobile team.
  • Added jQuery 3.x support: We officially added support for jQuery 3.x.
  • Reduced old IE support: jQuery Mobile 1.5 officially drops support for IE 10 and below and Android 4.0 and below
  • Bug fixes: We have closed and fixed hundreds of bugs getting to our lowest bug count since the initial release of jQuery Mobile!

For the first time, we have our full changelogdownload builder, and API documentation ready during the pre-release phase.




Note: please do NOT use the comments section of this blog post for reporting bugs. Bug reports should be filed in the jQuery Mobile Bug Tracker and support questions should be posted on the jQuery Forum.

If you have feedback on us doing our first beta release for jQuery Mobile 1.5, feel free to leave a comment below. Thank you.

A long overdue status update

Posted on by

It has been a long time since the release of jQuery Mobile 1.4, and we have started to get a lot of questions about the status and future of the project. First and foremost, I would like to say that we are very much still alive and working. Looking at the master branch, it may seem like there hasn’t been much happening. That is because we moved our development to a jQuery Mobile 1.5 branch while we worked on some very big breaking changes. This work ended up taking a lot longer than expected which has delayed the release of 1.5-beta more than we would have liked.

With the beta release of jQuery UI 1.12, we are almost ready to release and have just three more widgets to finish work on (see the open Pull Requests for panel, table, and selectmenu). Here is a quick status update of what we have been doing and have coming up in future versions.

We have combined efforts with the jQuery UI team to stop duplicating widgets. We now share the rock solid and newly re-written jQuery UI core. Components from jQuery UI we now incorporate include:

  • Core (now broken up into individual micro modules)
  • Button
  • Checkboxradio
  • Controlgroup
  • Accordion
  • Tabs
  • Widget factory

We have made sure all of our widgets now support the core jQuery UI Widget factory methods and options. Included in the new features is a classes option, which allows complete control over the look of your widgets, which will open up whole new custom theming possibilities. Our work with jQuery UI will continue in future versions. In upcoming versions we will be working to incorporate the remainder of jQuery UI features and widgets (including the ever popular datepicker) into jQuery Mobile. A big step forward for jQuery Mobile will also be the incorporation of the interactions like draggable, droppable, and sortable from jQuery UI.

We have also not forgotten the widgets which are specific to jQuery Mobile. We have completely re-written the navbar and table widgets for 1.5. Continuing the work on auto-enhancement we began in 1.4, the auto-enhancement based on data-role has been completely rethought from the ground up. It is now a stand-alone module that can work with widgets as well as any function or jQuery method. It is now highly optimized for speed and page reload. In complex pages with lots of enhancement, the auto-enhancements are faster than individual selectors and function calls.

The team has been working hard behind the scenes improving our code quality, testing, and infrastructure. In 1.5 we have cleaned up a lot of our current testing infrastructure and now also share testing infrastructure we developed with jQuery UI. We have also unified our use of AMD and are finishing up sharing a download builder. In the future, we plan to also share a theme and theme roller with jQuery UI. Our plan for theme roller is to both use CSS Chassis and the theme roller they intend to build, separating the theming from the JavaScript libraries.

We have also been looking into how to provide the best possible touch screen support. To this end we have made two major decisions moving forward:

  • Looking forward, we are also working to join efforts with PEP (Pointer Events Polyfill) and Hammer.js to improve our gesture support. Hammer.js is a very popular and robust gestures library that will help to improve jQuery Mobile while lowering maintenance costs for the team.
  • We will also be removing our vmouse abstraction in favor of PEP, a pointer events polyfill.

Lastly, we would like to address browser support. We have always attempted to support as many browsers as possible, but in order to move forward in the rapidly changing landscape we will be dropping support for many older browsers. Going forward we will support:

  • IE 11+
  • Chrome Current -1
  • Firefox Current -1
  • Safari 8+
  • iOS 8+
  • Android 4+
  • Windows Phone 8.1+

We have not removed any workarounds or bug fixes in 1.5, but we will no longer be accepting bug reports against other browsers and will remove workarounds in 1.6.

There are many more changes coming both in 1.5 and future versions, but this gives you an idea of the things that we have been working on and what is coming in the future.

Upcoming Releases: 1.0.1, 1.1, and beyond

Posted on by

With the start of a new year, we’ll be resuming our more regular team updates to keep you in the loop on what we’re working on here in the jQuery Mobile project. To kick things off, we’d like to share our current thinking on the next few releases so you can start planning ahead.

1.0.1 Maintenance release: Coming soon

We’re planning on releasing our first maintenance release for 1.0 within the next two weeks. This will consist of bug fixes and minor improvements to 1.0 after which we’ll focus on getting 1.1 out the door.

Version 1.1: Big improvements ahead

As soon as we released 1.0, we took a hard look at the framework to identify what areas needed the most improvement. The two items that quickly rose to the top of the list were improving the smoothness of page transitions and achieving true fixed toolbars. Both of these items have been a priority for the project since the beginning but we realized that to significantly improve these, we needed a complete re-think to embrace the constraints and opportunities of the wide range of browsers we support.

I’m happy to annouce that we have dramatically improved both of these items in our upcoming 1.1 release. We also have a few other goodies in slated for this release including AMD support (already in master) and a download builder tool (in-progress).

We’re planning on getting into a pattern of fairly regular, focused releases roughly every 3 months. Version 1.1 is the first of these releases and is slated for release sometime in mid/late February. Here’s a bit more on the key things that will be included:

  • AMD Support: Dependency management, flexible builds and improved code structure. Sorting out the dependencies is an essential step for a future download builder tool. AMD is a CommonJS standard that is being widely adopted by the JS community and breaks the boundaries between frameworks. In jQuery Mobile, we’re using AMD to express dependencies for the build scripts and to support our in-progress download builder tool, however we strip out all the AMD overhead in the final source files. It will just export a single “” AMD module if an AMD loader is present, the same way jQuery Core does it. Special thanks to James Burke (@jrburke) for jumping in and helping us polish our AMD implementation. We’re happy to report that this feature has now landed in master.
  • True fixed toolbars: Lightweight, CSS-based & broadly compatible.  When we first started developing the library, CSS support for position:fixed in mobile platforms was pretty much non-existent so our “fixed” toolbar solution dynamically re-positioned the toolbars each time you scrolled the page. Although it was a decent stopgap, the way mobile browsers would freeze the DOM during scroll would result in the toolbars briefly scrolling with the document which was impossible to completely fix. After a lot of prototyping and testing, we now have a complete re-write of this feature that provides true fixed toolbars on iOS5, Android 2.2+, Blackberry 7 & PlayBook, Kindle Fire, and most all desktop browsers while safely falling back to static toolbar positioning in other browsers. All in a lightweight, CSS-based approach that leverages native scrolling: demo the new fixed toolbars. We’ll cover fixed toolbars in more detail in a follow-up post.
  • Improved AJAX page transitions: Smoother, faster. We did a ton of work leading up to 1.0 to make our transitions as smooth as possible, but there were two significant constraints that we couldn’t avoid: the need to scroll the viewport between transitions and Android’s poor animation performance. In 1.1, we’ve embraced theses contraints and have come up with new animation sequence that effectively hides the page scrolling, completely re-designed the loading spinner to be visually unobtrusive, sped up the overall transition timing, added support for Firefox animations, and changed the default page transition to a fast and smooth fade out/in animation instead of slide. After much after a lot of testing and refinement, we’ve decided to use a 3D transform feature test to exclude poorly performing platforms like Android 2.x from the more complex slide, pop and and flip transitions so these will fall back to the default fade for all transitions to ensure a smooth experience. View an in-progress demo of the new transitions including a few experimental new animation types (note: above 1,000 pixel width screens, we switch to no transition so re-size your browser). If curious, this older iteration shows our best effort to improve transitions on Android 2.x and even with us dumbing down animations significantly, it’s pretty clear that Android simply isn’t capable of any page transitions other than fade. We’ll cover our thinking and process on the transition re-vamp in more detail in a follow-up post.

Heads up: touchOverflow to be deprecated in 1.1 – When we first introduced the touchOverflow feature, we saw it as a good way to leverage the native overflow support in iOS to bring true fixed toolbars and smoother transitions, even if it was for a fairly narrow set of devices at the time. Now with the significant changes to fixed headers and transition planned for 1.1, these will improve the experience in an almost identical way as touchOverflow, except it will work on a lot more platforms and with less complexity so we’ve decided to retire this feature. It will be deprecated at 1.1 and removed at 1.2. We do have future plans for addressing overflow regions with internal scrolling so a lot of the work we’ve done on touchOverflow will be re-purposed.

Version 1.2: New widgets and more improvements ahead

Our focus in 1.1 is improving key elements of the current library, but we plan on following up soon after with version 1.2. In this release, we plan on adding a few new components along with refinements to the existing widgets. We’re still prioritizing so things are subject to change, but here are two new things we’ve been working on for 1.2.

On deck, we have a popup component that is basically a small overlay that can hold any content or widget which makes it super easy to build a menu, tooltip, alert, dialog or even a lightbox with just a link and a few lines of HTML. This is different from a dialog because it actually overlays the current page instead of navigating to a new page so it has a different effect. It’s a bit easier to just play with this so here’s a rough popup proof of concept (yep, we know there are bugs). We’d like to thank Gabriel Schulhof from Intel for sharing their work on this plugin.

We also have a new utility called fetch links that surfaces the power of the AJAX navigation system for loading, enhancing and populating regions of the page. By adding a data-target attribute to any standard link, you can tell the framework to populate the an element of the page (target) with the contents of the link instead of doing a full page transition. This simple mechanism can be used to make a tab strip, a slideshow, create a “load more” or “pull to refresh” feature in a listview, or simply update any portion of the page based on user activity. You can specify what part of the href to pull in by adding a data-fragment attribute (we default to the page container). The href can either point to a local resource (#foo) or an external page (foo.html) and the framework will take care of auto-enhancing the markup for you. A data-method lets you specify all the standard jQuery AJAX methods (append, prepend, replace, etc.).  We’re working on documentation and demos now and will share a preview soon.

This is just a taste of what we have in store for 1.2. We’ll keep you updated as we move forward with planning for 1.2 in future blog posts.  Expect 1.2 to drop in early spring.

Development Update – Week of Sept. 19th

Posted on by

The jQuery Mobile team is now focused on bug-fixing and preparation for our first release candidate (RC1) for 1.0. We’ll be releasing RC1 within a week, just in time for the jQuery conference in early October. From there, we’ll have a few quick RCs with additional bug fixes before releasing 1.0 a bit later in October.


Meego 1.2: Grade A Support

Nokia was kind enough to send us a N950 phone for testing recently. Not only is Meego a super slick OS and the 950 an impressive piece of hardware, we were thrilled to find that jQuery Mobile worked beautifully the first time we fired it up. This has to be one of the easiest platform additions we’ve had and it shows how our focus on web standards and feature detection is really paying off.

Let’s hope we need more Meego devices in the future, it’s a really nice platform.

Cleanup of deprecated features: Take note

In preparation for jQuery Mobile 1.0, we’re removed a number of deprecated features. Please note that if you are running on an alpha codebase, many of these will be breaking changes.

Deprecated re-named page events – the deprecated beforechangepage (now pagebeforechange), changepage (now pagechange), and changepagefailed (now pagechangefailed) events references have been dropped in preparation for the 1.0 release. See the events API documentation and commit log for more info.

Removed support for the alpha signature of $.mobile.changePage() in preparation for  1.0. Folks now how to use the signature that requires the toPage (url or element) as the first arg, and options object as the 2nd. See the events API documentation and commit log for more info.

Removed deprecated navigation related properties: $.mobile.updateHash$.mobile.urlstack. See commit log for details.

Removed the deprecated $.fixedToolbars property in preparation for 1.0. See commit log for details.

Removed $.mobile.pageLoading() call which was  replaced by $.mobile.showPageLoadingMsg()and $.mobile.hidePageLoadingMsg(). See commit log for details.

Notable commits

Updated jQuery Mobile to run on jQuery core 1.6.4 to keep up with the latest and greatest.

Enable touch overflow scrolling on by default where supported – The $.mobile.touchOverflowEnabled is now true by default meaning that iOS5 devices will benefit from the improved animated page transitions and true fixed headers by default.  

New widgetinit event for users to enhance widgets and markup post widgetcreate

Flip toggle switch with change event bound, triggers multiple times (issue 2315) – Modified refresh() so that it checks to see if the value actually changed before firing off the “change” event.

Native checkboxes and radio buttons partially visible under custom controls (issue #1336) – Fixed by tweaking styles to float native controls rather than being inline, to fix height and properly hide checkboxes/radios. Thanks Wilto!

Arrow on formatted listviews no longer clickable (issue 1392) – Positions .ui-icon on lower z-index than .ui-btn-text, ensuring the click will register on the latter. Thanks Wilto!

Fixed $.jqmData() behavior to match $.fn.jqmData()

Can’t link to dynamically created data-role=”page” (issue 1243) – Modified loadPage() so that if the data-url lookup for a given page fails, that it look for the page via id (if it is an embedded page URL). This allows us to find dynamically injected pages that are un-enhanced and missing their data-url attributes.

Can’t link to dynamically created data-role=”page” (issue 1243)- Modified loadPage() so that if the data-url lookup for a given page fails, that it look for the page via id (if it is an embedded page URL). This allows us to find dynamically injected pages that are un-enhanced and missing their data-url attributes.

Fix for change page flicking in landscape orientation on iPad (issue 2474) – On iOS, giving focus to the ui-page element causes flashing during page animations/transitions. This is due to the CSS outline property which is applied when the page is given focus. Turning outlines off for all pages prevents the flashing.

Resolved label vertical alignment inconsistency of form elements (issue 2192). On wider screens or landscape orientation, for text-inputs, radios, sliders and checkboxes the vertical-align is top, for flip-switches and select-lists the vertical-align is baseline in all swatches. Thanks MauriceG!

Adjusted timing of when the orientation and resize classes are added to the body because the original mobileinit timing was limiting the ability to dynamically append jQuery Mobile. Thanks @martynsmith!

Removed the top “glow” border on icon-only buttons in split button lists (issue 1900). The border-radius was too large for the button which caused it to render as a straight line and break out of the button, removing this cleans up the appearance. Thanks MauriceG!

Fix for dialogs not working if $.mobile.ajaxEnabled = false (issue 2451 and 2202) – Modified the default click handler to check if the href is for an embedded page before bailing when ajaxEnabled = false. This allows us to navigate to internal/embedded pages/dialogs on the click versus waiting for the accidental hashchange that was the result of the browser’s default handling of hash fragments.

jqmHasData cleanup for jQuery 1.7 (issue 2455)- Changed behavior of .jqmData() only when called with no argument. It now returns undefined.

Fix for URL handling and PlayBook Webworks app (issue 2050) – Modified the url parser regexp so that we can find the double slash that precedes the authority. This is necessary so we can reconstruct resource urls used on some devices like Rim’s Playbook that use urls like:location:/dir1/dir2/file.html. Also modified makeAbsoluteUrl() so that it uses the new doubleSlash property in the object returned from parseUrl() instead of assuming that it is ok to use a double slash.

Namespace support for header and footer button icons (issue 1361) – When a namespace is used, the buttons in the header and footer icons wouldn’t appear. Fixed by mixin individual properties to options instead of calling .jqmData()

Fix for right/middle click issue in Firefox (issue 2438) – In Firefox, right-clicking on a linked-element results in the normal click event being fired instead of allowing the context menu to be displayed.

Navigation from one page back to multi-page template (issue 2406) – We now make sure that our hashchange resolves non-path hashes against the documentBase. This prevents the resulting changePath() call from incorrectly resolving against the URL for the current active (external) page. Also fixed a related issue where when push-state is turned on, the hashchange event is not fired when doing a window.history.back() from an external URL to an embedded page.

Page removal code for listviews removes embedded pages (issue 2432) – Added a new data attribute tag for pages loaded via ajax to keep track of whether to remove pages in this situation.

Fixed select element theme support (issue 2423) – Fixed a regression where directly applying a data theme to a select element no longer themes the select element. It only gets its theme from the parent, regardless of what you tell it.

Select menu refresh() improvements – fix refresh bug for new options of the same number as before

Improved qualifications so that iOS5 gets the old-style fixed headers and footers when touchOverflow is disabled (which is the default).

We’ve been nominated: Packt Publishing’s Open Source Awards

We’re honored to be nominated for Packt Publishing’s Open Source Awards in the “Mobile Toolkits and Libraries” category. The Voting stage begins on 19th September 2011 and closes on 31st October 2011, with the winners announced throughout the week commencing 7th November 2011. Vote now for jQuery Mobile!

Bartender: iOS-inspired tab widget

Bartender is a new jQuery Mobile-compatible plugin created by Sven Franck that adds a iOS-like bottom tab bar to your page. Here’s how Sven describes bartender:

Since starting to work with Jquery Mobile I have been looking for a more “app-like” navigation bar. There are examples abound, but most can be used on webkit-browsers only. Since I did not find a real cross-browser solution, I made one myself. I call it the bartender plugin.


  • based on JQM elements
  • CSS-only, no Jquery needed
  • tested on IE7+, latest FF, Opera, Chrome, Safari, Android, iOS
  • retina icons on all browsers except IE7-8
  • single retina-regular or separate sprites
  • All CSS-gradients

Get the latest builds on the jQuery CDN

To take advantage of the daily improvements happening in jQuery Mobile, be sure to check out out the new daily and latest builds that are now available on the jQuery CDN for hotlinking. This allows you to upgrade to the latest code without waiting for the next official release. Here are the three files to include in the head of your page to always be viewing the latest in Git:

<link href="" rel="stylesheet" type="text/css" />
<script src=""></script>
<script src=""></script>

If you just want to do a quick preview of our latest progress, visit to see a live demo of the docs synced every minute to the jQuery Mobile GitHub repo. This is helpful to check before filing an issue in the tracker to see if we’ve already fixed a bug you see in the last stable release. Please keep in mind that this the unstable, development version so we don’t recommend linking to the latest in a production site or app but it’s great for development and testing.

Development Update – Week of August 22nd, 2011

Posted on by

Beta 3: Landing in about a week

We’re hard at work on the last big changes we want to get in before moving onto the first RC for 1.0. We just landed pushState (see below). The other items on deck are finishing our move to transitions for page animations, adding a bit more extensibility for JS-driven apps, and bringing really slick transitons and fixed headers for iOS5. We’ll keep you updated as we get closer. We are targeting 1.0 for the end of September.

pushState landed: Now, clean URLs with Ajax-based navigation

We’ve been working very hard to add pushSate to jQuery Mobile. After many months and at least 6 complete attempts and the hard work of everyone on the team to get this right, we’ve finally landed this feature. Since we use Ajax-based navigation extensively throughout a jQuery Mobile experience, we need to track each page with a hash change which can make for some pretty long and unwieldy URLs, but it was a small price to pay to supporting the Back button and deep linking to pages.

Now with the addition of pushState, we’re able to update the URL to the clean, standard path in browsers that support this feature. Technically, we use history.replaceState() because this allows us to layer pushState support and an enhancement to our existing, and widely supported, hashchange-based navigation model. We essentially let the hash change happen, then replace the URL with the clean, full path of the page in browsers that support this capability. This works in later versions of desktop Safari, Chrome, Firefox and Opera as well as Android (2.2+ and Honeycomb) and the soon-to-be-released iOS5. In browsers that don’t support this feature, the hash-based URLs will continue to work as the did before to preserve the ability to share and bookmark URLs.

The pushState feature is implemented as an extension to the the navigation code so it can be easily pulled out of the build if it’s not needed on a project. It’s also possible to turn this feature off by setting the pushStateEnabledglobal option to false, like this:

$.mobile.pushStateEnabled = false;

Pro tip: How to view the source of a jQuery Mobile page

Since we use Ajax to pull multiple pages into the DOM, if you view the source you will see the code for the first page you visited unless you use a web inspector tool like Firebug to view the current DOM. Now with pushState in place, to view the source, simple refresh the page and view source. In browsers that don’t support pushState, you need to edit the URL to remove the redundant part of the hash to get full page path, then reload to view the source. Hopefully, this will make exploring the docs a bit easier for people.

Page animations: Moving from keyframe to transitions

One of the things we hear a lot of people asking for is smoother page transitions, and we couldn’t agree more. In the current system, we use keyframe-based animated page transitions (originally borrowed and tweaked from jQTouch). Keyframe animation tends to be more verbose, and its support is mostly limited to Webkit browsers (with Firefox 5 as a recent exception), we’ve been working to change over to using CSS transitions for our page animations.

The advantage of moving to CSS3 transitions is that they are already supported by recent versions of both Firefox and Opera in addition to Webkit so this paves the way much broader support for page animations over time on mobile and desktop browsers. Transitions are also a bit more concise syntactically than keyframes for our use case, which tends to be a 1-step transition from point A to point B.

We were also hoping that transitions would behave more smoothly on certain platforms, as the keyframe-based animations tend to drop frames on several of the Android devices we’ve tested. In testing, however, this switch isn’t the panacea we’d hoped. In extensive testing in our lab, we’ve found that there is little difference in the smoothness of animations between keyframe and transitions on the browsers that already supported animations — iOS, Android and BB6/PlayBook.

In Firefox, the latest versions of the desktop browser support transitions but the most up-to-date version of Firefox Mobile (beta 5) we tested on Android didn’t seem support them, even though we heard reports that it did. So, the desktop experience will be improved with this upcoming change, but not mobile (yet).

Opera Mobile (not Mini) does currently support transitions, but the performance was so slow that we’ve decided to not add in the Opera-prefixed transition rules until they release an update. Opera desktop 10.5 and later do a good job with transitions, but we can’t flip the switch for desktop without harming the mobile browser since they both use the same vendor prefix so this will be added as soon as an update lands and has decent uptake.

Why transitions aren’t smooth: A complex set of factors

There are a few factors that contribute to the smoothness of page transitions.

If the animations are hardware accelerated so they are efficiently rendered by the GPU instead of through the CPU and software, they will be markedly smoother. On iOS, even older versions of the iPhone, the OS does a very good job with hardware accelerating with both keyframe and transitions so animations are quite smooth. On the other hand, Android 2.x devices may only show 1-2 frames during a page transition on some devices because of the lack of hardware acceleration. Rendering bugs/glitches in the transitions/keyframe implementations for the platform can also contribute to blinkiness.  Ariya Hidayat from Sencha has a great article on the technical details of hardware acceleration. Because we support web standards for our transitions, all we can do on this front is try to use the most effective CSS we can and the rapid innovation in devices and mobile operating systems should move this part along quickly.

The size of the document and the amount of area being re-drawn can also cause flashes of blank screen zones or blinks. For example, webkit uses a 1024×1024 tile so if a transition or animation causes the canvas to shift by more than that, a blink may occur if the browser doesn’t paint that area fast enough.

Scrolling the page into position can also be a significant cause of the transition smoothness. Here’s why: When a new page is pulled in via Ajax to enable an animated page transition, it’s added to the DOM and positioned with CSS to queue up the animation. So if we’re moving with a slide transition, the new page will be placed to the right of the current page so we can slide to the right and animate the new page into view.

Since both pages share the same viewport, we position the top of the new page next to the top of the current page which means that if you’re scrolled down on a page and click a link, we need to first scroll up to the top of the current page, then begin the slide transition. This scroll to the top action produces a noticeable jump, especially in underpowered devices. Because of this, you’ll notice that if you start a page transition when already scrolled to the top of the page, it will not jump or blink at all in most cases (some platforms always blink). We also remember and restore the original scroll position of a page that you revisit, so if you are scrolled down on a page and hit Back, you will see the current page scroll up, the slide animation will occur, then you will see the page scroll down to your original position.

We’ve tried every trick in the book to minimize the scrolling artifacts, but we now realize that this can’t be completely mitigated while still supporting the wide range of platforms the jQuery Mobile wants to cover without taking a fresh approach to the problem.

The future: Overflow and fixed positioning, for real this time

The way to eliminate this scrolling jumpiness is simple in theory: if each page has a height as tall as the screen allows, and scrolls internally using overflow, the browser will always be scrolled to the top. Unfortunately, regular CSS overflow has terrible support on mobile browsers, with almost no platform offering momentum scrolling via CSS overflow, and on iOS devices a user needs to scroll these regions with 2 fingers instead of 1. The only way to work around this currently is to use a JavaScript-based polyfill to mimic the scrolling using CSS3, with scripts such as our experimental scrollview plugin, scrollability, iScroll, or a host of other momentum scroller scripts.

Unfortunately, these scripted approaches tend to share a common flaw: they only work in a very narrow range of mobile browsers, usually just iOS and Android (with a lot of caveats and performance issues). Since scroller scripts need to intercept events to trigger the scrolling, they can prevent interaction with form elements and introduce a host of other serious usability issues if not applied with care and lots of testing. These scripts also need to be carefully targeted through support tests (and unfortunately UA detection), as they run the risk of making a page completely unusable on the mobile (and desktop) platforms they do not support. For web applications that are accessible on the public web, we don’t feel that this is an acceptable tradeoff for smoother transitions and fixed toolbars. In an installed native app, however, these scripts become a much more feasible option because the risk of usability problems is greatly reduced when only one browser needs to be supported.

For these reasons, we’ve tried our best to build on top of native browser scrolling, so we’re very excited by iOS5’s upcoming support for a touch-targeted version of overflow:auto|scroll , and proper support for position:fixed to allow for internal scrolling regions with the native momentum scrolling with CSS. This  will enable us to bring both truly “fixed” toolbars and super smooth transitions, all by using web standards and very little additional code. We’re working now on landing this as an improvement for 1.0 so we’re ready when iOS5 is released.

Think of this as an enhancement to what we have now: if the overflow: and -webkit-overflow-scrolling:touch properties are supported, we can make sure toolbars stay fixed and eliminate the scrolling jumps between transitions. Coupled with iOS’s already-excellent hardware-accelerated transitions, we’ll be very close to native performance.

Don’t other mobile platforms already support overflow?

Yes, but there’s a catch. Both Android Honeycomb and the Blackberry PlayBook support overflow: properties, but that’s not quite enough. If we simply placed an overflow: auto CSS rule on the page body, other popular mobile platforms like older versions of Android and iOS would essentially just clip off the content and make it effectively inaccessible (yes, you can can do a two-finger scroll gesture in iOS but nobody knows that).

The smart thing about Apple’s implementation for iOS5 is that they added an additional CSS property -webkit-overflow-scrolling:touch that allows us to test for this touch scrolling property and, if supported, add in the overflow rules for just those browsers. This is the only safe way to target overflow without resorting to complex and unmaintainable user agent detection.

We will be working with device and browser makers to encourage support for both these CSS-based properties because we strongly believe that this a critical piece needed to build rich mobile web apps.  So let’s all ask other mobile companies to follow Apple’s lead here and support both -webkit-overflow-scrolling:touch and overflow: properties ASAP.

The project will add any vendor-prefixed additions to touch scrolling property if, for example, Opera, Firefox or Microsoft added this support. Once people see how much better page transitions and fixed toolbars are on iOS5, we’re hoping this will be supported quickly by other browsers.

JS-based scroller scripts may still have a place in this new world as a polyfill for browsers that dont’ yet support these new CSS capabilities but we see this as a brief, interim tool in the evolution of the mobile web. Once implemented, it will likely be easier to add such a shim to your codebase as well.

The team has spent a ton of time working on trying to improve transitions because we know this is an incredibly important feature. We hope this helps to provide a bit of useful detail on the challenges we face and how we plan on moving forward.

Notable commits this week

Fix to check the domCache option before rebinding the page remove on select menu. When closing a fullpage select menu we need to check the domCache option before rebinding the page remove handler. If domCache is true the page remove wasn’t bound in the first place, so binding it on menu close will cause the removing of a page that mustn’t be removed. Thanks SamuelKC!

Anchor buttons active class not removed properly (Issue #1405) – Moved assignment of $activeClickedLink to the vclick handler in charge of adding the active state

Fixed closing the custom select dialog – The picker wasn’t being closed correctly. Thanks MichelHartmann!

Ellipses too aggressive – truncating overflow early on lists, buttons, form elements (issue 779) – Adjusted padding on buttons

Sponsor thanks: Adobe

We’d like to thank Adobe Systems Inc. for both contributing a generous donation at the start of the jQuery Mobile project and for sponsoring the development time of Kin Blas (@kinblas) for the past year. To top it off, they also recently just hired another mobile team member, John Bender (@johnbender) to work on the project in a dedicated way. Kin and John are an important part of jQuery Mobile team and their amazing talent and drive has been critical to the success of this project. we wanted to acknowledge Adobe for their generous support as a premier sponsor of the project. Thanks Adobe!

As you probably know, Adobe is has been included jQuery Mobile in the new Dreamweaver CS 5.5 release and includes a lot of great tools to make it easy to build mobile-optimized sites and apps with jQuery Mobile.

If you are looking to support the jQuery Mobile project, we are actively looking for corporate sponsors to provide donations or commit to long-term developer involvement. To learn more, please contact Todd Parker, project lead to discuss opportunities for supporting the project and open source.

New jQuery Mobile pagination plugin

Team member Scott Jehl of Filament Group just posted a cool new pagination plugin that makes it super simple to allow for swiping between separate jQuery Mobile pages. Perfect for navigating through photo galleries, articles and more.

The Pagination plugin creates touch-drag navigation between separate HTML pages. Simply add this plugin to your page and link together documents via ordinary HTML anchors. The linked pages will pre-fetch, and in browsers that support touch events, you’ll be able to drag between the linked pages, while desktop users can navigate with mouse or keyboard. Like all navigation in jQuery Mobile, this plugin ties into your browser’s history, so bookmarking, and using the browser’s back and forward buttons work as expected!

Photoswipe: Updated version out

The very cool Photoswipe plugin adds a slick gallery slideshow tool that is compatible with jQuery Mobile. PhotoSwipe is a FREE HTML/CSS/JavaScript based image gallery specifically targeting mobile devices.

The latest 2.0.2 version adds the ability to drag swipe between photos and adds a number of refinements.

For a nice example of jQuery Mobile, responsive design and Photoswipe, check out this portfolio site.

[contentblock id=1 img=gcb.png]

Development Update – Week of August 8th, 2011

Posted on by

We’re really happy about the Beta 2 release and are now working on the last batch of improvements we want to land for 1.0. The team is very close to landing the re-vamped transitions and pushState branches and we’re actively fixing lots of bugs as we go.

jQuery Mobile nominated for two .net Awards 2011

We’re happy to see that jQuery Mobile has been nominated for for two .Net awards – the annual Awards are organised by .net magazine – the world’s bestselling magazine for web designers. The categories are Innovation of the Year & Open Source App of the Year! We’d love your support by voting for jQuery Mobile.

Listview filter callback added: Hook to add custom search logic

Now If you want to change the way in which list items are filtered, ie fuzzy search or matching from the beginning of the string, you can configure the callback used internally by defining $.mobile.listview.prototype.options.filterCallback during mobileinit or after the widget has been created with $("#mylist").listview('option', 'filterCallback', yourFilterFunction). Any function defined for the callback will be provided two arguments. First, the text of the current list item and second the value being searched for. A truthy value will result in a hidden list item. The default callback which filters entries without the searchValue as a substring is described below:

function( text, searchValue ){
  return text.toLowerCase().indexOf( searchValue ) === -1;

The documentation for lists has been updated to add this feature. Thanks to project707 for all the hard work on this feature and the helpful input of jeffholmes.

Notable commits this week

Added a simple filterCallback in the listview options to delegate complex search logic to end users. This allows you to drop in any search pattern matching logic needed without adding too much complexity to the core filtering code.

Fix for Split Button List dialog having no background and weird line from background image. Thanks jgable!

Brought back the page content div theme inheritance from b1 (issue 2221) Thanks to abdulqadir for the suggestion.

Fix nested waiting-for-dom for initializePage. Using dom-ready within dom-ready meant that initializePage went to the end ofthe queue. That brought problems when other dom-ready code expected jQM to beset up, capable of changing pages and so on. But because $.mobile.pageContaineris also set in initializePage, changePage and others didn’t work. Thanks moll!

Fixed an error in the array reference that was causing support tests to not test properties as they should.

New book: Master Mobile Web Apps with jQuery Mobile

Matt Doyle recently released a new book on jQuery Mobile called “Master Mobile Web Apps with jQuery Mobile“. It’s very detailed 300+ page eBook in PDF format that is well-written and updated to reflect the latest Beta 2 release. Matt will be updating the book when we hit 1.0 and offer a free update for people who buy the book now.

The book is now available for sale. A sample chapter and demo to-do app featured in the book are available too. Here’s a description:

“Master Mobile Web Apps with jQuery Mobile”” teaches you how to quickly create great mobile web apps using jQuery Mobile. It’s a fully-up-to-date comprehensive guide which covers:

• How to get up and running quickly with the latest version of jQuery Mobile (Beta 2)

• Building pages, buttons, toolbars, dialogs, forms and interactive list views — using nothing but HTML

• Theming your apps to give them a unique look and feel

• How to integrate your own JavaScript code with the jQuery Mobile API

• How to create a fully-functioning, multi-user task manager app using jQuery Mobile, PHP and MySQL

Sponsor thanks: Jive Software

We’d like to thank Jive Software for contributing the time and expertise of their developer, Ghislain Seguin, to the core jQuery Mobile team. Ghislain has been a tremendous help over the last three months and we wanted to recognize the generous donation that Jive Software has made to this project. Jive Software is a software company from Palo Alto that has an enterprise social networking platform that allows companies to engage employees, customers, and the social web.

If you are looking to support the jQuery Mobile project, we are actively looking for corporate sponsors to provide donations or commit to long-term developer involvement. To learn more, please contact Todd Parker, project lead to discuss opportunities for supporting the project and open source.

[contentblock id=1 img=gcb.png]

Development Update – Week of July 25th, 2011

Posted on by

Beta 2: Coming early next week

We’re completing final testing now for a release of Beta 2 early next week. We’re really excited about all the improvements and bug fixes we’ve landed in the last month and can’t wait for this to be released. We’ll keep everyone updated on Twitter as we get closer to the release.

In case you’re wondering what it takes to test jQuery Mobile, here is a sneak peek at us testing the DOM cache changes on just a subset of our more popular mobile devices. This less than half of our test library. One fun tool that we’ve been using recently is Scott’s cool Drive-in tool that lets you drive a browser on one device and all the others will follow along as you navigate around. It uses long polling so some fo these devices wander off course pretty quickly, but it’s really helpful when testing certain features.

New DOM cache management: On by default

Since animated page transitions require that the page you’re on and the one you’re transitioning to are both in the DOM, we add pages to the DOM as you navigate around. Until now, those pages would continue to stay in the DOM until you did a full page refresh so there was always a concern that we could hit a memory ceiling on some devices and cause the browser to slow down or even crash.

This week, we added a simple mechanism to keep the DOM tidy. It works like this: whenever a page is loaded in via Ajax, it is flagged for removal from the DOM once you navigate away to another page (technically, on pagehide). If you return to a deleted page, the browser may be able to retrieve the file from it’s cache, or it will re-request it fro the sever if needed. In the case of nested lists, we remove all the pages that make up the nested list once you navigate to a page that’s not part of the list. Pages that are included in a multi-page setup won’t be affected by this feature at all – only pages brought in by Ajax are managed this way by jQuery Mobile.

A new page option called domCache controls whether to leave pages in the DOM as a way to cache them (the way things used to work) or keep the DOM clean and remove hidden pages (the new way). By default, domCache is set to false to keep the DOM size actively managed. If you set this to true, you need to take care to manage the DOM yourself and test thoroughly on a range of devices.

To set the domCache option on an individual pages in order to selectively cache a page, you can either add the data-dom-cache="true" attribute to the page container or set it programmatically like this:{ domCache: true });

The domCache option can also be set globally. This is how to turn DOM caching back on so it works like it did originally:

$ = true;


New global config option: autoInitializePage

For advanced developers who want more control over the initialization sequence of a page, we’ve just added a new autoInitializePage global config option. Setting this to false disables auto-initialization of plugins on page creation to allow developers to manipulate or pre-process markup before manually initializing the page later on. By default, this option is set to true so things work just like they always did.

API documentation: Template ready for volunteers!

We’ve been trying a number of different ideas internally on how to add in more traditional API-style docs to the demos & docs site and have a proposed solution that essentially adds a simple tab strip to all the plugin detail pages where we can document the options, methods and events that a more technical developer might need. We’ve tried to strike a balance between presenting the simpler, markup-based approach that a designer may need and the more advanced script-driven details that a developer requires.

We’re looking for volunteers to help us apply this style of docs throughout the rest of the system. To participate, learn more about on how to help us write API docs. Thanks to ovargas27 for already jumping in and lending a hand.

Notable commits this week

Exposed automatic initialization selectors on most widgets – The new option, initSelector is accessed through each of the widget plugins (select, slider, etc.) that expose options through the widget factory. This is used to define the selectors (element types, data roles, etc.) that should be used as the trigger to automatic initialization of each widget plugin. This allows developers to apply auto-initialization in more flexible ways.

Restored degradeInputs page option (issue 2123) – We originally had a degradeInputs option as part of the page plugin that would allows you to find a certain type of form element (say input type=”range”) and degrade it into another type (input type=”number”) either because the browser support is so uneven or if you built a custom enhancement for the primary type (like a custom slider) and you don’t want the native implementation to interfere. Now added back in a decoupled plugin, but the API is the same.

Prevent ‘Unspecified error’ when we use an IFrame on IE9 (issue 2064)  – Add try/catch block to prevent the error. Thanks SamuelKC

jQuery Mobile: Up and Running – Digital early release

O’Reilly has just posted a digital early release version of their forthcoming book “jQuery Mobile: Up and Running” by Maximiliano Firtman. It’s well-written and covers Beta 1 code so it’s really up-to-date for a book. Here’s the description from O’Reilly:

jQuery Mobile: Up and Running teaches you how to create responsive, Ajax-based interfaces that work on tablets as well as smartphones, so you don’t have to rebuild everything for different platforms. You don’t need programming skills or previous experience with jQuery or HTML5 to get started. This book shows you exactly what you need to know.

  • Understand how jQuery Mobile, HTML5, and CSS3 work on smartphones and tablets
  • Build a single project for a variety of platforms, including iOS, Android, BlackBerry, Firefox, webOS, and Internet Explorer
  • Convert web content built with jQuery Mobile into apps ready for sale and distribution in every application store
  • Learn how to create HTML5 semantic code prepared for mobile and tablet devices
  • Work with jQuery Mobile components, form elements, list views, and themes

Plugin spotlight: Mobiscroll

If you’re looking for a spinner-style date and time picker that works with jQuery Mobile, check out the new mobiscroll plugin. It has a really slick looking interface and is built to be easily themeable (though I don’t believe it uses the jQuery Mobiel theme framework). This widget supports selecting dates, times and seems easily configurable for custom picker situations. It works with both touch input and mouse/scrollwheel input. Best of all, it is tested in iOS4, Android 2.2, Android 2.3, Chrome, Safari, and Firefox. Check out the project homepage, documentation and demo pages to learn more or download a zip of the code to give it a try.

Get the latest builds on the jQuery CDN

To take advantage of the daily improvements happening in jQuery Mobile, be sure to check out out the new daily and latest builds that are now available on the jQuery CDN for hotlinking. This allows you to upgrade to the latest code without waiting for the next official release. Here are the three files to include in the head of your page to always be viewing the latest in Git:

<link href="" rel="stylesheet" type="text/css" />
<script src=""></script>
<script src=""></script>

If you just want to do a quick preview of our latest progress, visit to see a live demo of the docs synced every minute to the jQuery Mobile GitHub repo. This is helpful to check before filing an issue in the tracker to see if we’ve already fixed a bug you see in the last stable release. Please keep in mind that this the unstable, development version so we don’t recommend linking to the latest in a production site or app but it’s great for development and testing.

Development Update – Week of July 18th, 2011

Posted on by

Beta 2 very soon, Beta 3 in the wings

As you can see from the last few blog posts, we’ve been making some big improvements under the covers to make the library more extensible, robust and performant in addition to adding some nice developer tools as we go. At this stage, we are going to focus on final testing for the current feature set so we can release Beta 2 in the next week or so.

We still have a number of important improvements that we feel are critical to land but don’t want to hold up Beta 2, so we’ve decided to move these into third beta release. In Beta 3, we will be adding a few items that we haven’t had time to completely test and bullet-proof yet like DOM size management, pushState support and extensibility hooks for developers. The improved cross-browser page transitions are close to landing, but we’re not yet sure whether they will make it in for Beta 2 or 3 at this point.

This additional beta will push out our project 1.0 release by a few weeks, but we feel that these improvements are critical to making our first major release a success. Now, onto the things we’ve been working on this week!

Page wrapper: Now optional

The framework is now more flexible with document structure so now the data-role=page wrapper element is optional. This will ease integration with existing sites, as well as mashups with external content. Previously, if you didn’t wrap your page in a container with this role, the framework wouldn’t enhance the page widgets but now it doesn’t need a page wrapper in the markup to trigger initialization.

The page, header, content, and footer data-role elements have always been optional, but now with this page wrapper change, there is no required markup at all – just start building you page content. Here is an example of a page with none of these structural elements in the markup and everything works great.

Behind the scenes, the framework will inject the page wrapper if you don’t include it in the markup because it’s needed for managing pages, but the starting markup can now be extremely simple. Note that in a multi-page setup, you are required to have page wrappers in your markup in order to group the content into multiple pages.

Widgets: Now decoupled for flexible builds

We’ve wanted to decouple all our widgets from the page plugin for a long time now and we’re happy to announce that we just landed this change. So what exactly does decoupled mean anyway? Well, the individual widgets and utilities have always been broken out into separate script files. However, the page plugin was responsible for handling the auto-initialization all of the official plugins found in the markup at page creation. This situation made it impossible to remove plugins you don’t need without causing errors, and generally set a bad precedent for future widget additions.

Now, pretty much all the widgets in the jQuery Mobile library are completely decoupled so they can simply be deleted if not needed for a particular project. This change allows you to dramatically reduce the size of the library by only including the specific set of widgets or features you need, in addition to the handful of required, core files. While we still plan to do more decoupling and cleanup, the following files are now decoupled and can safely be removed from the make file before you do a custom build:

  • page sections (header/content/footer, previously in page plugin)
  • collapsible
  • controlgroup
  • fieldcontain
  • fixheaderfooter
  • button
  • checkboxradio
  • select
  • slider
  • textinput
  • links (ordinary link theming previously in page plugin)
  • listview
  • navbar
  • grid

We will work on a dependency map because a few widgets rely on others to work. For example, the button markup plugin is called by many of the widgets above, so it can only be excluded but if you’re not using any of the widgets that depend on buttons.

We’re still working out our recommendations for mapping plugin dependencies and decoupling things even further. Ultimately, this will be surfaced in a download builder tool, so stay tuned!

New “create” event: Easily enhance all widgets at once

While the page plugin no longer calls each plugin specifically, it does dispatch a “pagecreate” event, which most widgets use to auto-initialize themselves. As long as a widget plugin script is referenced, it will automatically enhance any instances of the widgets it finds on the page, just like before. For example, if the selectmenu plugin is loaded, it will enhance any selects it finds within a newly created page.

This structure now allows us to add a new create event that can be triggered on any element, saving you the task of manually initializing each plugin contained in that element. Until now, if a developer loaded in content via Ajax or dynamically generated markup, they needed to manually initialize all contained plugins (listview button, select, etc.) to enhance the widgets in the markup.

Now, our handy create event will initialize all the necessary plugins within that markup, just like how the page creation enhancement process works. If you were to use Ajax to load in a block of HTML markup (say a login form), you can trigger create to automatically transform all the widgets it contains (inputs and buttons in this case) into the enhanced versions. The code for this scenario would be:

$( markup that contains widgets... ).appendTo( ".ui-page" ).trigger( "create" );

Create vs. refresh: An important distinction

Note that there is an important difference between the create event and refresh method that some widgets have. The create event is suited for enhancing raw markup that contains one or more widgets. The refresh method that some widgets have should be used on existing (already enhanced) widgets that have been manipulated programmatically and need the UI be updated to match.

For example, if you had a page where you dynamically appended a new unordered list with data-role=listview attribute after page creation, triggering create on a parent element of that list would transform it into a listview styled widget. If more list items were then programmatically added, calling the listview’s refresh method would update just those new list items to the enhanced state and leave the existing list items untouched.

Notable commits

Updated Valencia theme to match new CSS syntax (issue 2087) – After our request for help on this, and Mayank Varia came through with an update for this theme so thanks!

Error in new page.sections js when data-add-back-btn=”true” on page (issue 2119) -Fixed a problem when pages have the data-add-back-btn set to true causing an error. Thanks jgable!

Email input type doesn’t receive input field styles (issue 2117) –  When using email as the input type for an input field, jQuery Mobile does not correctly enhance them post-decoupling. Thanks commadelimited! Also fixed URL and tel input types for the same regression.

Hide loading message for loadPage should be to not show the loading message – It’s default use case is to fetch a page that is not yet active so this is distracting. However, changePage should cause it to show because loadPage is being called during a page change. This was causing the loader to show when using the new page precache option.

Get the latest builds on the jQuery CDN

To take advantage of the daily improvements happening in jQuery Mobile, be sure to check out out the new daily and latest builds that are now available on the jQuery CDN for hotlinking. This allows you to upgrade to the latest code without waiting for the next official release.

Here are the three files to include in the head of your page to always be viewing the latest in Git:

<link href="" rel="stylesheet" type="text/css" />
<script src=""></script>
<script src=""></script>


Please keep in mind that this the unstable, development version so we don’t recommend linking to the latest in a production site or app but it’s great for development and testing.

Development Update – Week of July 11th, 2011

Posted on by

New test device donations!

We’d like to thank a number of companies who really came through this week for the project by donating a fresh batch of devices to the test lab here at Filament Group. This week, we’d like to take the time to thank HP Palm, Nokia and Grupo.Mobi for donating devices to the project. Here’s the rundown:

  • TouchPad – This is a cool tablet running the latest Palm WebOS 3.0 software. Early testing indicates that CSS support is really improved from WebOS 2.0 so the pages render cleanly and look great. We have a few small tweaks to make, mostly focused on the positioning of toolbars, menus and loader but we’re in great shape otherwise. Orientation changes don’t seem to trigger a re-flow of the layout so pages zoom instead of adjsuting to the screen width, but maybe this will be fixed in an update. We really hope that Palm HP roll the browser improvements into the WebOS 2.0 because that version has fairly serious CSS rendering issues.
  • Nokia N8 – We’ve been waiting to get a newer Nokia device and we were pleasantly surprised that jQuery Mobile renders really quite well on this slick little phone. The biggest gotcha is that the S60 based browsers (including this latest phone) don’t correctly add hashchange changes in the history stack in the browser so the Back button doesn’t work with our Ajax navigation. We were hoping this would have been fixed by now, but it looks like we’ll have to bump this platform down to B grade support which translates to a fully enhanced experience, except without Ajax navigation (full page refreshes and no transitions).
  • Samsung Galaxy Tab 10.1 – This is our first device running the Android Honeycomb OS and it’s a very nice device — very lightweight and responsive.  The jQuery Mobile demos and docs seem work render and work great on this device, no big surprises. CSS based transitions are still pretty chunky but rounded corners are finally anti-aliased. We are truly living in the future. Donated by Grupo.Mobi
  • Google Nexus S – We finally have a phone running Android 2.3 so we can finally ditch the emulators. So far, 2.3 looks great, no major snags and really great rendering performance, smooth scrolling and a very responsive screen. A very nice device. Donated by Grupo.Mobi

The jQuery Mobile project relies on the generous donation of devices, developer time and financial support from individual developers and companies to continue our work so if you can help out, please contact the project lead, Todd Parker, for more details.

Gradients: Expanded platform support

We just added additional vendor-prefixed rules for CSS3 background gradients to increase browser support of this feature. There are now Opera (-o) and Internet Explorer (-ms) prefixed gradient rules in addition to the standard, non-prefixed version. Thanks to Paul Irish CCS3 Please for the slick formatting ideas for these rules:

background-image: -webkit-linear-gradient(top, #3c3c3c, #111); /* Chrome 10+, Saf5.1+ */
background-image:    -moz-linear-gradient(top, #3c3c3c, #111); /* FF3.6 */
background-image:     -ms-linear-gradient(top, #3c3c3c, #111); /* IE10 */
background-image:      -o-linear-gradient(top, #3c3c3c, #111); /* Opera 11.10+ */
background-image:         linear-gradient(top, #3c3c3c, #111); /* Standard, non-prefixed */

This now means that our background gradients work in WebKit, Firefox, Opera, Internet Explorer 10 and any other browser that supports the standard, non-prefixed rule. As we mentioned in last week’s post, we had to remove the -ms filter gradient rules due to a rendering issue in IE9 that conflicts with border radius and won’t be fixed by Microsoft. This means that older versions of IE will just see a flat background color, including WP7 and the forthcoming Mango release. More info on this bug and decision can be found at issue #2046.

We’re looking for a volunteer to roll this new syntax into the Valencia theme so please comment in the issue if interested.

Loading message: Now configurable at runtime

Previously, you could customize the loading text message on initialization as an option, but you couldn’t modify it on the fly from within a page if you wanted a different message for the particular situation. We just landed an improvement so you can set the contents of the loading message programmatically at runtime. The syntax is the same as it’s always been, you can just use it more flexibly:

$.mobile.loadingMessage = "My custom message!";

Configurable swipe event thresholds added

There were a number of hard-coded constants in the swipe code. For developers who need to tweak those constants  to allow a greater vertical displacement and still register a swipe, this new feature allows them to be adjusted. Thanks to mlitwin for contributing this.

  • scrollSupressionThreshold (default: 10px) – More than this horizontal displacement, and we will suppress scrolling
  • durationThreshold (default: 1000ms) – More time than this, and it isn’t a swipe
  • horizontalDistanceThreshold (default: 30px) – Swipe horizontal displacement must be more than this.
  • verticalDistanceThreshold (default: 75px) – Swipe vertical displacement must be less than this.

Page pre-fetch page option added

Another cool feature we just added is the ability to flag pages that should be pre-fetched by Ajax. For example, if you’re building a photo gallery with each photo on a separate HTML page, you can pre-fetch the previous and next pages in the slideshow sequence so they will display immediately without the Ajax loader. It’s simple to use: just add a data-prefetch attribute to any link in the page and the framework will lazy load the pages into the DOM in the background. We recommend building your apps as a series of individual, linked HTML documents for each page for performance yet we see a lot of people using multi-page templates and even nested lists (yikes) as a way to essentially pre-load content. We hope this feature will encourage developers to use standalone, external pages with selective pre-caching instead of relying as much on multi-page setups.

<a href="foo/bar/baz" data-prefetch>link text</a>

Pages can also be pre-fetched programmatically by calling $.mobile.loadpage( url ). Pre-fetching links will naturally cause additional HTTP requests that may never be used, so it’s important to use this feature only in situations where it’s highly likely that a page will be visited.

Coming soon in Beta 2

We’re hoping to land the following changes next week in preparation for Beta 2. Here’s a sneak peek so you can test out these branches and give us feedback.

Expanded browser support for transitions

Our original page transitions were based on jQTouch and they are really quite nice. Unfortunately, these were built with CSS keyframe animations that only work in iOS, WebOS and Android.  Since we released Alpha 1, a number of browsers have added support for CSS transitions so we’re working now on switching over to CSS transitions. We will be addingd vendor-prefixed CSS rules for Opera, Firefox, and Webkit so it makes the CSS a bit heavier but brings animated page transitions to a wider range of platforms and browsers. Follow our progress on the issue page and check out the transitions branch to test drive the new transitions in action.

Automatic DOM size management

Since jQuery Mobile loads multiple pages into the DOM via Ajax to enable the animated page transition, we’ve obviously been concerned about memory use as people navigate through a series of pages. We’re working on adding a feature to keep the DOM clean and manageable and it works like this: if a page is brought into the DOM via Ajax, it is removed from the DOM when the page is hidden (transitioned out). If you want to return to this page, the browser retrieve the cached version and load that in instead of re-requesting it so we’re leveraging the native browser’s capabilities to manage memory use. Note that pages loaded as part of a multi-page template won’t be removed, only external pages loaded in via Ajax. This feature will be turned on by default, but can be configured via an option. Specific pages can be protected from removal by adding a data- attribute the page container. View the commit for this feature and give it a try out the disable-ajax-dom-caching branch and give us feedback.

Delayed auto-init

This change allows developers to delay the auto-init call until whenever they want to call it manually. This is useful when building dynamic applications. Read the commit message and preview the autoinit-option branch to give it a try.

Notable commits this week

Fix for URL handing in navigation with relative URLs – Now you can call $.mobile.loadPage with a relative path and it will load the page correctly, regardless of whatever page you are linking from.

Removed the nonHistorySelectors option, which was no longer in use after the nav refactor.

Fix for rounded corners in collapsible Set (issue #1931) – The first section in a collapsible set has rounded bottom corners when not expanded (shouldn’t have .ui-corner-bottom class), and the last section does not have rounded corners when collapsed (should have .ui-corner-bottom class). Thanks beatryder!

Checkbox list with same name do not allow multiple selection (issue #1851) – The checkboxradio plugin treats a check box list with same value for the name attribute for the check boxes as radio buttons. Thanks Tigbro!

Rounded corner login for inset lists  with two items (issue 1996) – The top corner style doesn’t get applied in an inset list with two items (other number of items work fine). Thanks eugenb1!

Close button behavior fixes (Issues #1618#1692,#1750)- Abstracted out some of the page hide behavior to fix issues with the close button not returning focus to the button after closing. Also fixes an issue where a full page custom menu would open as a misplaced small custom menu the second time it opens (if the menu was closed via the custom close button).

Changed padding-box to padding for -moz-background-clip per this spec

Slider onChange event is launched on page load (issue #1526) – the onChange event was triggered when the page loads  instead of only when the slider’s value is changed.

Disappearing text in IE7 (issue #2058) – Text would only appear on mouseover in certain circumstances due to a rendering bug in IE (shocker!). Fixed by adding the zoom: hack.

New Packt book: jQuery Mobile First Look

There is a lot of excitement about jQuery Mobile and we’re happy to see so many books coming out, even though we’re still in Beta. Packt Publishing has a nice overview of the framework in their new book:  “jQuery Mobile First Look” which is available now. Here’s what it covers:

  • Easily create your mobile web applications from scratch with jQuery Mobile
  • Learn the important elements of the framework and mobile web development best practices
  • Customize elements and widgets to match your desired style
  • Step-by-step instructions on how to use jQuery Mobile
  • eBook available as PDF and ePub downloads and also on PacktLib

Interesting articles

In case you don’t follow @jquerymobile on Twitter, here are some great new tutorials and articles on jQuery Mobile we’ve seen this week:

Using and customizing jQuery Mobile themes – Adobe Developer

How to style buttons with jQuery Mobile – O’Reilly Answers

jQuery Mobile in Visualforce pages – Force blog

jQuery Mobile – adding Local Storage – Raymond Camden’s ColdFusion Blog

Building a jQuery Mobile HTML5 App with PhoneGap for Drupal 7, Part 2 – Jeff Linwood

How to create and self-init a jQuery Mobile plugin – Gist by Scott Jehl

Blackberry Contest

jQuery Mobile works great on the the new PlayBook tablet so this is a great opportunity to win some cool prizes. Are you creating an innovative BlackBerry WebWorks app using the jQuery Mobile framework for the BlackBerry PlayBook or BlackBerry Smartphone or thinking about jumping in?  There’s never been a better time with big prizes up for grabs in the Most Innovative BlackBerry WebWorks app on the BlackBerry PlayBook tablet and BlackBerry 6 challenge!


Get the latest builds on the jQuery CDN

To take advantage of the daily improvements happening in jQuery Mobile, be sure to check out out the new daily and latest builds that are now available on the jQuery CDN for hotlinking. This allows you to upgrade to the latest code without waiting for the next official release.

Here are the three files to include in the head of your page to always be viewing the latest in Git:

<link href="" rel="stylesheet" type="text/css" />
<script src=""></script>
<script src=""></script>


Please keep in mind that this the unstable, development version so we don’t recommend linking to the latest in a production site or app but it’s great for development and testing.