jQuery Mobile Beta 3 released!

Posted on by

The jQuery Mobile team is happy to announce the release of Beta 3. This brings the last batch of features and API changes to the library before 1.0. Beta 3 includes some really great improvements: pushState support, beforechangepage event for building dynamic page, slick fixed headers and transitions for the forthcoming iOS5 platform, and a long list of fixes and improvements. We’ve also decided to delay our planned switch from keyframes to transitions for animated page transitions because the browser support and performance isn’t up to par yet in our testing. More info on what’s new below.

We’re now feature-complete and working on our first RC for the 1.0 release which is targeted for the end of the month.

Demos & docs | Key changes | Supported Platforms | Change log | Upgrade notes | Download & CDN

KEY CHANGES

pushState: 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. On the  RIM PlayBook, there is a small browser bug that doesn’t update the URL correctly unless you refresh the page so copying a link from this device may not be correct, we’re working with them to track down a fix.

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.

New beforechangepage event: Simple hook for building dynamic pages with JavaScript

jQuery Mobile allows pages to be pulled into the DOM dynamically via its default click hijacking behavior, or through manual calls to $.mobile.changePage(). This is great for applications that generate HTML pages/fragments on the server-side, but there are sometimes cases where an application needs to dynamically generate page content on the client-side from JSON or some other format. This may be necessary for bandwidth/performance reasons, or because it is the data format of choice for the server they are interacting with.

For applications that need to generate page markup on the client-side, it’s important to know about the notifications that are triggered during a $.mobile.changePage() call because they can be used as hooks into the navigation system that will allow you to generate your content at the appropriate time.

A call to changePage() will usually trigger the following event notifications:

  • pagebeforechange
    • Fired off before any page loading or transition.
    • NOTE: This event was formally known as “beforechangepage”.
  • pagechange
    • Fired off after all page loading and transitions.
    • NOTE: this event was formally known as “changepage”.
  • pagechangefailed
    • Fired off if an error has occurred while attempting to dynamically load a new page.

These notifications are triggered on the parent container element ($.mobile.pageContainer) of pages, and will bubble all the way up to the document element and window.

For applications wishing to inject pages, or radically modify the content of an existing page, based on some non-HTML data, such as JSON or in-memory JS object, the pagebeforechange event is very useful since it gives you a hook for analyzing the URL or page element the application is being asked to load or switch to, and short-circuit the default changePage() behavior by simply calling preventDefault() on the pagebeforechange event.

To illustrate this technique, take a look at this working sample. In this sample, the main page starts off with a list of categories that the user can navigate through. The actual items in each category are stored in a JavaScript object in memory, for illustrative purposes, but the data can really come from anywhere.

To learn more, visit the new documentation page.

iOS5: Dramatically improved page transitions and true fixed toolbars

The team has spent a ton of time working on trying to improve transitions and fixed toolbars because we know these are important features to developers. After spending hundreds of hours working on refinements, we now believe that the path to substantial, cross-platform improvements in these areas can only happen when mobile platforms start supporting overflow properties natively. JavaScript-based momentum scroller scripts are too heavy, unresponsive and narrowly compatible to be a way forward.

That’s why we’re very excited by iOS5′s upcoming support for a touch-targeted version of overflow:auto , and proper support for position:fixed which allows for internal scrolling regions with the native momentum scrolling with CSS. In Beta 3, we’ve added an enhancement layer to leverages these new CSS capabilities to will enable us to bring both truly “fixed” toolbars and super smooth transitions in iOS5, all by using web standards and very little additional code.

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 by placing each page in a container with internal scrolling. Coupled with iOS’s already-excellent hardware-accelerated transitions, we now can build interfaces that are very close to native performance and appearance.

The only downside we’ve seen is that the -webkit-overflow-scrolling:touch property seems to disable the events to scroll you to the top of the page when the time is tapped in the status bar, but we’re hoping Apple will fix this by the time iOS5 goes public.

In Beta 3, we’ve implemented this native scrolling behavior as a new global option called touchOverflowEnabled. For now, this feature is off by default to give us a a bit more testing and debugging (custom selects and toolbars can be a bit flaky). We plan on turning this feature on by default by 1.0 and we’re hoping iOS 5 is out by then too.

For those using the iOS5 beta now, check out this demo with touchOverflowEnabled activated on to see how smooth the experience can be. For everyone else, check out the video.

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 we found in testing that their implementation of overflow wasn’t smooth enough so pages would stutter and hang during scrolling, leading to an unusable experience. If you’d like to test drive the overflow performance on these other platforms to see why we exclude them, check out this demo that skips the feature test. Note: we’re not excluding any browsers from the overflow:auto styles in this link and this can make the pages unusable on many platforms (iOS and Android) – do not use this code on your site!

More importantly, targeting overflow correctly is a major issue. If we simply placed an overflow: auto CSS rule on the pages, 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. 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 don’t yet support these new CSS capabilities but we see this as a brief, interim tool in the evolution of the mobile web.

Switch from keyframe to transitions for animations: Post 1.0

We currently use keyframe-based animated page transitions whose support is mostly limited to Webkit browsers (with Firefox 5 as a recent exception). We’ve been spending a lot of effort in recent months working to switch over to using CSS transitions for our page animations which is a W3C web standard and paves the way much broader support for page animations over time.

In final testing, however, the switch to transitions 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. The bigger disappointment is that the mobile counterparts of the browsers that prompted this switch either don’t support transitions at all (Firefox Mobile) or have poor performance (Opera Mobile) and we can’t flip the switch for the desktop versions without impacting their mobile counterparts since they both use the same vendor prefix.

After a lot of deliberation, we’ve decided that although this is the right direction for the project, this isn’t the right time to make the switch. The new plan is to shelf this code and plan on switching to transitions as soon as we feel that the browsers we’re targeting have the support and performance level that makes this a positive step forward. This will happen post-1.0, but probably within the next 3-6 months.

Download builder: In the works

Now that we’ve decoupled most of the UI widgets, we’ve set the stage for there to be a download builder. This will let you build a custom version of jQuery Mobile to only include the parts you need. For example, you could just use the core files to add Ajax-based navigation with pushState and leverage some of the touch events and other utilities with a very lightweight build (roughly 11k). Or, you could add in specific UI widgets like form elements, listviews, etc. to create an optimized build. We’re aiming to have a download builder tool as part of 1.0.

Platform support in Beta 3

As of Beta 3, we’ve pretty much covered our target platforms for 1.0. At this stage, jQuery Mobile works on the vast majority of all modern desktop, smartphone, tablet, and e-reader platforms. In addition, feature phones and older browsers are also supported because of our progressive enhancement approach. We’re very proud of our commitment to universal accessibility through our broad support for all popular platforms.

Our graded support matrix was created over a year ago based on our goals as a project and since that time, we’ve been refining our grading system based on real-world device testing and the quickly evolving mobile landscape. To provide a quick summary of our browser support in Beta 1, we’ve created a simple A (full), B (full minus Ajax), C (basic) grade system with notes of the actual devices and versions we’ve been testing on in our lab.

The visual fidelity of the experience is highly dependent on CSS rendering capabilities of the device and platform so not all A grade experience will be pixel-perfect but that’s the nature of the web. We’ll be adding additional vendor-prefixed CSS rules to bring transitions, gradients and other visual improvements to non-WebKit browsers in future releases so look for even more added visual polish as we move towards 1.0.

A-grade – Full enhanced experience with Ajax-based animated page transitions.

  • Apple iOS 3.2-5.0 beta: Tested on the original iPad (3.2 / 4.3), iPad 2 (4.3), original iPhone (3.1), iPhone 3 (3.2), 3GS (4.3), and 4 (4.3 / 5.0 beta)
  • Android 2.1-2.3: Tested on the HTC Incredible (2.2), original Droid (2.2), Nook Color (2.2), HTC Aria (2.1), Google Nexus S (2.3). Functional on 1.5 & 1.6 but performance may be sluggish, tested on Google G1 (1.5)
  • Android Honeycomb- Tested on the Samsung Galaxy Tab 10.1
  • Windows Phone 7: Tested on the HTC 7 Surround
  • Blackberry 6.0: Tested on the Torch 9800 and Style 9670
  • Blackberry 7 NEW – Tested on BlackBerry® Torch 9810
  • Blackberry Playbook: Tested on PlayBook version 1.0.1 / 1.0.5
  • Palm WebOS (1.4-2.0): Tested on the Palm Pixi (1.4), Pre (1.4), Pre 2 (2.0)
  • Palm WebOS 3.0 - Tested on HP TouchPad
  • Firebox Mobile (Beta): Tested on Android 2.2
  • Opera Mobile 11.0: Tested on the iPhone 3GS and 4 (5.0/6.0), Android 2.2 (5.0/6.0), Windows Mobile 6.5 (5.0)
  • Kindle 3: Tested on the built-in WebKit browser included in the Kindle 3 device
  • Chrome Desktop 11-13 – Tested on OS X 10.6.7 and Windows 7
  • Firefox Desktop 3.6-4.0 – Tested on OS X 10.6.7 and Windows 7
  • Internet Explorer 7-9 – Tested on Windows XP, Vista and 7 (minor CSS issues)
  • Opera Desktop 10-11 - Tested on OS X 10.6.7 and Windows 7

B-grade – Enhanced experience except without Ajax navigation features.

  • Blackberry 5.0: Tested on the Storm 2 9550, Bold 9770
  • Opera Mini (5.0-6.0) - Tested on iOS 3.2/4.3
  • Windows Phone 6.5 – Tested on the HTC
  • Nokia Symbian^3 - Tested on Nokia N8 (Symbian^3), C7 (Symbian^3), also works on N97 (Symbian^1)

C-grade – Basic, non-enhanced HTML experience that is still functional

  • Blackberry4.x: Tested on the Curve 8330
  • All older smartphone platforms and featurephones – Any device that doesn’t support media queries will receive the basic, C grade experience

Not Officially Supported – May work, but haven’t been thoroughly tested or debugged

  • Meego – Originally a target platform, but Nokia decision to relegate this platform to “experimental”, we are considering dropping support.
  • Samsung Bada – The project doesn’t currently have test devices or emulators, but current support is known to be fairly good. Support level undecided for 1.0.

Beta 3 upgrade notes

Renamed the beforechangepage and changepage events to pagebeforechange and pagechange respectively. This was done to match the page widget naming of its notifications. Left the triggers for the old events in place but with DEPRECATED comments. Renamed the properties of the data object passed to the page events.

Change log

Added “fromPage” option to changePage(). Restored from the navigation re-work. Added “dataUrl” option to changePage(). This allows a caller to specify a page element to change to, but specify an alternate URL for location display purposes. This is useful for dynamic applications that re-use and over-write existing page content to avoid overwhelming the DOM. Renamed the “beforechangepage” and “changepage” events to “pagebeforechange” and “pagechange” respectively. This was done to match the page widget naming of its notifications. Left the triggers for the old events in place but with DEPRECATED comments. Renamed the properties of the data object passed to the page events.

Modifications to changePage() – Moved the setting of isPageTransitioning after the beforechangepage notification, mModified the trigger(“beforechangepage”) call to pass the args to changePage() as an object since trigger only expects one data arg.

Restore the “lastScroll” behavior to work with the new DOM cleanup (issue #1774) – Added a property to each urlHistory item object, allowing us to remember previous scroll distances when returning to a page that has since been removed from the DOM. Before this change, this number was stored in data on the page element, so it is lost when the page is removed after pagehide. Also, this change removes a reference in memory that we were keeping to the $activeClickedLink on each page. We stored this in attempt to refocus a link after returning to a page. Unfortunately, it doesn’t seem that this data can be retained after pages are removed from the DOM, outside of somehow remembering a unique selector string to reach that element again.

No way to stop a link from being followed with some custom event (tap, taphold) (Issue 1464) - Modified triggerVirtualEvent() so that it returns the virtual event instead of the isDefaultPrevented() result of the virtual event. Updated all references to triggerVirtualEvent() that relied on the boolean return value to instead check the isDefaultPrevented() call on the event now returned. Updated mouseEventCallback() to propagate the iDefaultPrevented(), isPropagationStopped(), and stopImmediatePropagation() values from the virtual event on to the original mouse event. Modified the “taphold” trigger code to create a new $.Event() instead of passing the stale vmousedown event.  Added clearTapTimer() which is called from a new vmouseup binding, to prevent the timer from firing between the tie the finger/mouse goes up and the click event is dispatched.

Changed minscroll distance to 250 pixels – We were originally using 50% of the screen height but this was a large value on tablets so we’ve switched to a fixed 25px value by default. This is a configurable option.

Fixed throttledresize (issue 2390)- Fixed typo: ‘throttledResize’ => ‘throttledresize’ that was preventing this feature from working on some platforms. Thanks hbunjes!

Flip toggle switches don’t animate when tapped (Issue 2346) – Tweaked code to match markup and enable animations

Single tap triggers two actions, especially in Android (Issue 1925) - Trigger the list item and keyboard return/space key up to the “click” event instead of “vclick”. This delays the dismissal of the custom select menu until the click event, thereby avoiding the case where the menu disappears before the browser dispatches it’s synthesized mouse events (in the touch case) with a target of whatever element was underneath the menu.

Clear active link on vclick so there can be only one active link at a time (Issue #2017) – This prevents situations where multiple items on a page could have the active state if a user clicked after an Ajax request has started

Changed look and feel of custom select options to match the new, simpler checkbox/radio styles for selects using a custom menus

Added ipv6 support to urlparse regex (issue #2362) – We can now parse ipv6 IP addresses in the Ajax nav system.

Flip toggle switch value toggle (Issue 2345) - We now track whether or not the user has modified the value of the switch control. If so, we don’t toggle it’s value on mouseup.

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.

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

Download

We provide CDN-hosted versions of jQuery Mobile for you to include into your site. These are already minified and compressed – and host the image files as well. It’ll likely be the fastest way to include jQuery Mobile in your site.

CDN-Hosted JavaScript:

CDN-Hosted CSS:

Copy-and-Paste Snippet for CDN-hosted files (recommended):

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0b3/jquery.mobile-1.0b3.min.css" />
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script src="http://code.jquery.com/mobile/1.0b3/jquery.mobile-1.0b3.min.js"></script>

 

If you want to host the files yourself you can download a zip of all the files:

ZIP File:

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.

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:



If you want to a quick preview of our latest progress, visit www.jquerymobile.com/test. This is a live demo of the docs synced live 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 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.

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:



If you want to a quick preview of our latest progress, visit www.jquerymobile.com/test. This is a live demo of the docs synced live 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.

jQuery Mobile Beta 2 Released!

Posted on by

The jQuery Mobile team is happy to announce the release of Beta 2. This brings a bunch of big improvements to the library including: decoupled widgets so you can include only the components you need, DOM cache management for less memory use, a page pre-cache option, more flexible page structure, improved checkbox and radiobutton designs, advanced features for developers building dynamic JS-driven sites, and even broader device support. It’s been a busy 5 weeks since Beta 1 and we’re really happy with the direction and velocity of the project as we head towards 1.0.

Beta 3 coming – We have a few key improvements we want to land before we switch gears to focus on bug fixes and performance for the first RC for 1.0. Look for Beta 3 within the next month that will include pushState support, improved transitions with support for Firefox and Opera, and even more developer extensibility hooks.

Note that jQuery Mobile 1.0 will require jQuery core 1.6.2 as a baseline. Going forward, we’ll be supporting the two latest major versions of core but we’re starting with a cleaner baseline for launch. Here is a summary of what’s new and improved in Beta 2.

Demos & docs | Supported Platforms | Key changes | Change log | Upgrade notes | Download & CDN

Platform support: Expanded for Beta 2

In Beta 2, we’ve added broader support of CSS gradient rules for Opera and Firefox, brought support and testing for Android 2.3 phones and Honeycomb tablets, HP Palm WebOS 3.0 tablets, and added B grade support for newer Nokia S60 devices.

We’re happy to announce that jQuery Mobile Beta 2 now supports Nokia Series 60 smartphones. We’ve had to bump this platform down to B grade support because this platform doesn’t properly support hashchange events in the history stack. This means that Nokia devices will get the enhanced experience except without the Ajax-based animated page transitions.

At this stage, jQuery Mobile works on the vast majority of all modern desktop, smartphone, tablet, and e-reader platforms. In addition, feature phones and older browsers are also supported because of our progressive enhancement approach. We’re very proud of our commitment to universal accessibility through our broad support for all popular platforms.

Our graded support matrix was created over a year ago based on our goals as a project and since that time, we’ve been refining our grading system based on real-world device testing and the quickly evolving mobile landscape. To provide a quick summary of our browser support in Beta 1, we’ve created a simple A (full), B (full minus Ajax), C (basic) grade system with notes of the actual devices and versions we’ve been testing on in our lab.

The visual fidelity of the experience is highly dependent on CSS rendering capabilities of the device and platform so not all A grade experience will be pixel-perfect but that’s the nature of the web. We’ll be adding additional vendor-prefixed CSS rules to bring transitions, gradients and other visual improvements to non-WebKit browsers in future releases so look for even more added visual polish as we move towards 1.0.

A-grade – Full enhanced experience with Ajax-based animated page transitions.

  • Apple iOS 3.2-5.0 beta: Tested on the original iPad (3.2 / 4.3), iPad 2 (4.3), original iPhone (3.1), iPhone 3 (3.2), 3GS (4.3), and 4 (4.3 / 5.0 beta)
  • Android 2.1-2.3: Tested on the HTC Incredible (2.2), original Droid (2.2), Nook Color (2.2), HTC Aria (2.1), Google Nexus S (2.3) NEW. Functional on 1.5 & 1.6 but performance may be sluggish, tested on Google G1 (1.5)
  • Android Honeycomb NEW – Tested on the Samsung Galaxy Tab 10.1
  • Windows Phone 7: Tested on the HTC 7 Surround
  • Blackberry 6.0: Tested on the Torch 9800 and Style 9670
  • Blackberry Playbook: Tested on PlayBook version 1.0.1 / 1.0.5
  • Palm WebOS (1.4-2.0): Tested on the Palm Pixi (1.4), Pre (1.4), Pre 2 (2.0)
  • Palm WebOS 3.0 NEW – Tested on HP TouchPad
  • Firebox Mobile (Beta): Tested on Android 2.2
  • Opera Mobile 11.0: Tested on the iPhone 3GS and 4 (5.0/6.0), Android 2.2 (5.0/6.0), Windows Mobile 6.5 (5.0)
  • Kindle 3: Tested on the built-in WebKit browser included in the Kindle 3 device
  • Chrome Desktop 11-13 – Tested on OS X 10.6.7 and Windows 7
  • Firefox Desktop 3.6-4.0 – Tested on OS X 10.6.7 and Windows 7
  • Internet Explorer 7-9 – Tested on Windows XP, Vista and 7 (minor CSS issues)
  • Opera Desktop 10-11 - Tested on OS X 10.6.7 and Windows 7

B-grade – Enhanced experience except without Ajax navigation features.

  • Blackberry 5.0: Tested on the Storm 2 9550, Bold 9770
  • Opera Mini (5.0-6.0) - Tested on iOS 3.2/4.3
  • Windows Phone 6.5 – Tested on the HTC
  • Nokia Symbian^3 NEW – Tested on Nokia N8 (Symbian^3), C7 (Symbian^3), also works on N97 (Symbian^1)

C-grade – Basic, non-enhanced HTML experience that is still functional

  • Blackberry4.x: Tested on the Curve 8330
  • All older smartphone platforms and featurephones – Any device that doesn’t support media queries will receive the basic, C grade experience

Not Officially Supported – May work, but haven’t been thoroughly tested or debugged

  • Meego – Originally a target platform, but Nokia decision to relegate this platform to “experimental”, we are considering dropping support.
  • Samsung Bada – The project doesn’t currently have test devices or emulators, but current support is known to be fairly good. Support level undecided for 1.0.

KEY CHANGES

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 finally 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 UI 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 header/content/footer
  • collapsible
  • controlgroup
  • fieldcontain
  • fixheaderfooter
  • button
  • checkboxradio
  • select
  • slider
  • textinput
  • links theming
  • 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:

$( ...new 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.

New DOM cache management feature: 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.

For Beta 2, 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:

elem.page({ 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:

$.mobile.page.prototype.options.domCache = true;

 

Page pre-fetch page option added

Another cool feature we recently 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.

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.

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 jquery.mobile.event.js 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.

Backtrack: We’ve switched back from vclick to click for links

In Beta 1, we decided to use our custom vclick event for handling Ajax links to improve responsiveness and to hide the URL bar on the iPhone and Android phones. Even though we did quite a bit of testing before landing this for Beta 1, we began to hear feedback that this change was causing some significant issues out in the wild including:

  • Multiple click events causing navigation and form element issue – In certain situations, when tapping an element, tap/click events seem to fire twice on links and is due to edge cases where the target of the touch event and mouse event don’t match due to how the browsers calculate tolerances for these events. This is most pronounced on Android 2.1, but affected most WebKit-based browsers to varying degrees when a tap events occured near the edge of an element.
  • Click handlers in custom scripts didn’t “work” anymore – if a script bound only to click events on the document, the global vclick feature could interfere because the touch events may supercede click events so it events wouldn’t appear to trigger.

Based on a lot of detailed testing and analysis, we’ve decided to roll back to using standard click events on links instead of using the custom vclick event because it’s the only reliable way to support all our target browsers. There are two important things to note in this change:

  • URL bar hiding isn’t quite as slick as in Beta 1, but link handling is obviously much more important. The good news is that there is still a significant improvement from Alpha 4.1: although URL bar may appear briefly it overlays the page in iOS instead of pushing down content and causing a re-draw blink. We methodically tried every technique we could to keep the URL bar hidden but there is unfortunately a Safari bug (even in the latest Beta 2 of iOS 5) that makes it impossible to hide the bar reliably.
  • The useFastClick global option introduced in Beta 1 is now removed because we’re not using vclick globally anymore on links and don’t recommend doing this going forward. We hardly knew ye…

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.

Checkboxes and Radio buttons: New, Simpler design

Now onto fun fun stuff: the previous design for checkboxes or radio buttons highlighted the entire button background to the active state. We’ve wanted to tweak this for some time because having the full button switch tothe active state could be a bit overwhelming visually, especially on a check list with multiple items selected.

To make these controls a bit simpler visually and also fall in-line with standard UI conventions, now just the check or radio form element flips to the active state instead of the whole button. Note that the horizontal, grouped check and radio groups still flip the while label to the active state color because we hide the form element in these cases.

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 an earlier blog 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. This change has been rolled into both the Default and Valencia themes.

All code formatting: Cleaned up & JSlint-ready

Thanks to an intense 24 hour sprint by Rick Waldron of Bocoup, all our code formatting now conforms with with the jQuery core styleguide for whitespace and organization. This also makes the library work with JSLint and other validation tools.

API documentation: Now underway

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.

Beta 1 upgrade notes

The useFastClick global option introduced in Beta 1 is now removed because we’re not using vclick globally anymore on links.

Change log

Fix for cached page removal breaking dialog sized select menus (issue 2181)

Added a configurable timeout to $.mobile.loadPage to give pages that are being fetched from cache a little time to load before a loading message appears. Note: if the delay ends up needing to be longer than 300ms or so to suit some devices,we may not keep this feature.

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

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.

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  ryanneufeld !

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.

XSS risk with XHR level2 cross domain request (issue #1990) - jQuery mobile can load other domain’s html so there is a security risk, as it can XSS or display fake contents. Created new option for $.mobile.ajaxCrossDomainEnabled and set the defaultto false

Switch back to processing link clicks on the “click” event because it really is the only reliable way across all the devices we support. Fixes any of the double click events, missed clicks or click event not being processed. Also, removed the useFastClick option and documentation references since using vclick isn’t a workable solution for links.

mobile.changePage not working on BB5 (issue #1907)- multi-page docs don’t work, and clicking a link cause a ”page is too large” error. The fix for this was to tweak the regex related.

Fix for the mysterious “page is too large” error on Blackberry 5 prior to beta 1. Turns out this little code was enough to invoke the error: ”/dir1/dir2″.replace(/\/?/, “”); Rewrote the regexp in path.makePathAbsolute() that was stripping leading slash, and trailing filename/slash. This gets around the problem. Special thanks to @adambiggs for helping us test 33 iterations when trying to narrow down the cause!

Fixed form buttons no longer submitting forms in Internet Explorer 8

Corrected corner styling issue with listview refresh on growing lists (issue #1470) – If list items were appended and the refresh() method called, the correct corners were not being assigned.

Fixed incorrectly calculated path of forms (issue #1923)- Added code to calculate whether to choose the documentUrl or the page Url in the case where an action is not specified on a form element. Fixed bug in the navigation “submit” handler where an error was being thrown if “type” was not specified.

Hitting enter in search filter now doesn’t not submit the form – Since this is a client-side filter, we want to prevent submitting the form. Thanks adamvaughan

Remove unnecessary ajax call and duplicate DOM nodes when refreshing a page with a dialog visible (issue #1913) - This was causing duplicate dialog elements inthe DOM. Thanks Sunpig!

Controlgroup now filters on visible buttons when adding first and last classes for rounded corners. If you hide the first or last button in a controlgroup and then call refresh on it, it won’t add the right classes to the newly promoted first/last button.

Removed param “refresh” sent to .controlgroup since it’s not a $.widget

Tweaked styles for select menu text running off side of list – Seen when using the custom select menus only

Updated Valencia theme for the updated check and radio styles

Fixed swatch letter typo for E button in theme CSS (Issue #1894)- it said ui-bar-d instead of ui-bar-e. . Thanks app42!

Moved collapsible sets (accordions) in docs into a standalone page for better visibility, updated section nav on other pages and index page to link to it.

Moved our form binding into the _registerInternalEvents callback, to ensure it’s not bound until after mobilinit.

Download

We provide CDN-hosted versions of jQuery Mobile for you to include into your site. These are already minified and compressed – and host the image files as well. It’ll likely be the fastest way to include jQuery Mobile in your site.

CDN-Hosted JavaScript:

CDN-Hosted CSS:

Copy-and-Paste Snippet for CDN-hosted files (recommended):

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0b2/jquery.mobile-1.0b2.min.css" />
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script src="http://code.jquery.com/mobile/1.0b2/jquery.mobile-1.0b2.min.js"></script>

 

If you want to host the files yourself you can download a zip of all the files:

ZIP File:

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:

elem.page({ 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:

$.mobile.page.prototype.options.domCache = 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="http://code.jquery.com/mobile/latest/jquery.mobile.min.css" rel="stylesheet" type="text/css" />
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.min.js"></script>

If you just want to do a quick preview of our latest progress, visit www.jquerymobile.com/test 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:

$( ...new 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="http://code.jquery.com/mobile/latest/jquery.mobile.min.css" rel="stylesheet" type="text/css" />
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.min.js"></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 jquery.mobile.event.js 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 – Salesforce.com 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="http://code.jquery.com/mobile/latest/jquery.mobile.min.css" rel="stylesheet" type="text/css" />
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.min.js"></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 4th, 2011

Posted on by

Improvements on deck for beta 2

We have a bunch of improvements that we’re working to land for beta 2 which is slated for release in about 2 weeks. Here are a few key features that we’re excited about adding. Each of these is in a branch for testing so let us know what you think:

  • Expanded browser support for animated page transitions - we’re working now on switching over to CSS transitions (from Webkit-only keyframe animations) and adding vendor-prefixed CSS rules for Opera and Firefox. View issue page and preview the “transitions” branch to test drive them now.
  • DOM size management feature - We’re working on adding a feature that will remove pages loaded in into the DOM via Ajax when the page is hidden (transitioned out). If you want to return to this page, the browser may be able to retrieved 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. View the commit for this feature and give it a preview the “disable-ajax-dom-caching” branch.
  • Pre-fetch page feature - Another very cool feature we’re working on 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. By adding a data-prefetch attribute to any anchor element in the page and the framework will lazy load the pages into the DOM in the background. View the commit for this feature and preview in the “prefetch” branch.

We hope to land these in master next week after we complete testing. After beta 2 is out, we have a even more improvements in the pipeline: pushstate support, more extensible navigation model, self-initializing widgets and more.

IE9/WP7 Mango: Removing gradient support

The jQuery Mobile framework uses CSS-based gradients to reduce our need for images to make pages load faster. We support the various vendor-prefixed gradient syntaxes for Webkit and Firefox and will soon be adding Opera prefixed rules too. In addition, we currently include the -ms-filter syntax to support gradients in IE 8/9.

In preparation for the upcoming WP7 Mango update (based on the IE9 rendering engine), we were doing gradient testing and found some disappointing results: In both IE 9 and Mango, the -ms-filter gradient rules have serious rendering issues when combined with rounded corners, causing the background color of the element to break out of the corner radius (see screenshot). We’ve discussed this with Microsoft and the browser team won’t be fixing this rendering issue because the filter syntax is deprecated as they are moving to the standard CSS gradient syntax for IE 10.

So we’re left with a tough choice: if we leave the -ms-filter gradient rules in our CSS so gradients look good in IE 8, it will seriously degrade the experience in IE 9/Mango with rounded corners. At this time, we are planning on removing -ms-filter gradient rules so IE 8/9 and Mango will display flat background colors throughout the UI. This will enable rounded corners to display cleanly in IE 9/Mango (IE 7/8 don’t support border-radius). We think this is the best course of action and places us in a better position for the future.

Plugin developers: Widget template

If you are creating jQuery Mobile plugins, you can make it easy on users by following similar patterns to the core widgets: use the UI widget factory and auto-initialize your widget by data- attributes on page creation. To help everyone out, we created a simple gist showing how to set up a jQuery Mobile widget.

Help support the project

We’re always looking for help and support since we’re a very small team with limited resources.

  • Donate test devices – we’re looking to expand out test lab so we’re looking for more smartphones and tablets. We especially need Nokia, Samsung Bada, new Palm WebOS 3.0 devices, and Android devices. If you have contacts at manufacturers you can connect us with, we’d appreciate that too
  • Donate developer time – we are looking for dedicated developers that can help us fix bugs, write unit tests and documentation.
  • Donate funds – individuals can donate to the jQuery project and we’re looking for corporate sponsorship to support the project.

Please contact Todd Parker to start up a conversation on how you can help the project. We appreciate your support!

Thanks to Group.Mobi: New test device donations

We’d like to thank Terence Reis and the rest of the Grupo.Mobi team for their generous donation this week of a new Samsung Galaxy Tab 10.1 and Android 2.3 phone for our test lab. Grupo.Mobi specializes in mobile app, game and site development, advertising and marketing for a broad range of top-tier companies. We really appreciate their help and support!

 

Notable Commits this week

XSS risk with XHR level2 cross domain request (issue #1990) - jQuery mobile can load other domain’s html so there is a security risk, as it can XSS or display fake contents. Created new option for $.mobile.ajaxCrossDomainEnabled and set the default to false

Updated latest build to use 1.6.2 – In the demos & docs pages.

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="http://code.jquery.com/mobile/latest/jquery.mobile.min.css" rel="stylesheet" type="text/css" />
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.min.js"></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 June 27th, 2011

Posted on by

The overall response to the Beta 1 release has been very positive and we appreciate all the words of encouragement we’ve heard on our progress to date. As with any major release, there are bound to a be a few snags so let’s start off with the one major problem we’ve seen: click handling on links.

Beta 1: Issues with vclick for handling links

In Beta 1, we switched to using our custom vclick event for handling Ajax links to improve responsiveness and this change seemed to help hide the URL bar consistently on the iPhone and Android phones. The vclick feature is a custom synthetic event that normalizes events by listening for touch and click events. It works at the document level and looks for duplicate events on the same target and will go with the one that bubbles up first and cancels the duplicate event.

Even though we did quite a bit of testing before landing this for Beta 1, we began to hear feedback that this change was causing some significant issues out in the wild including:

  • Multiple click events causing navigation and form element issue – In certain situations, when tapping an element, tap/click events seem to fire twice on links and is due to edge cases where the target of the touch event and mouse event don’t match due to how the browsers calculate tolerances for these events. This is most pronounced on Android  2.1 but affects most WebKit-based browsers when you tap near the edge of an element.
  • Click handlers in custom scripts didn’t “work” anymore – if a script binds only to click events on the document, the vclick feature could interfere because the touch events may supercede these click events so it won’t appear to trigger.
  • Disabling vclick globally didn’t work – To compound the issue, we had recommended using a new $.mobile.useFastClick option to disable the vclick feature globally but there was an issue with this option in Beta 1 that prevented this from working as designed.

Our solution: Roll back from vclick to click globally

Based on a lot of detailed testing and analysis, we’ve decided to roll back to using standard click events on links instead of vclick because it’s the only reliable way to support all our target browsers. If you test on the latest builds with this change integrated, things should work reliably again. There are two important things to note in this change:

  • URL bar hiding isn’t quite as slick as in Beta 1, but link handling is obviously much more important. The good news is that there is still a significant improvement from Alpha 4.1: although URL bar may appear briefly it overlays the page in iOS instead of pushing down content and causing a re-draw blink. We methodically tried every technique we could to keep the URL bar hidden but there is unfortunately a Safari bug (even in the latest Beta 2 of iOS 5) that makes it impossible to hide the bar reliably.
  • The useFastClick option is now removed in the latest code because we’re not using vclick globally anymore on links and don’t recommend doing this going forward. We hardly knew ye…

Checkboxes and Radio buttons: New, Simpler design

Now onto fun fun stuff: the previous design for checkboxes or radio buttons highlighted the entire button background to the active state. We’ve wanted to tweak this for some time because having the full button switch tothe active state could be a bit overwhelming visually, especially on a check list with multiple items selected.

To make these controls a bit simpler visually and also fall in-line with standard UI conventions, now just the check or radio form element flips to the active state instead of the whole button. Note that the horizontal, grouped check and radio groups still flip the while label to the active state color because we hide the form element in these cases.

All code formatting: Cleaned up & JSlint-ready

Thanks to an intense 24 hour sprint by Rick Waldron of Bocoup, all our code formatting now conforms with with the jQuery core styleguide for whitespace and organization. This also makes the library work with JSLint and other validation tools.

Next major release: Beta 2

We’re working on some exciting additions to the library including broader transition support, pushState and more. For the near term, we’re going to target the Beta 2 release within the next 2 weeks to get these click changes and other improvements into the stable release so the pace of releases will start being much more frequent.

Notable Commits this week

Switch back to processing link clicks on the “click” event because it really is the only reliable way across all the devices we support. Fixes any of the double click events, missed clicks or click event not being processed. Also, removed the useFastClick option and documentation references since using vclick isn’t a workable solution for links.

mobile.changePage not working on BB5 (issue #1907)- multi-page docs don’t work, and clicking a link cause a ”page is too large” error. The fix for this was to tweak the regex related.

Fix for the mysterious “page is too large” error on Blackberry 5 prior to beta 1. Turns out this little code was enough to invoke the error: ”/dir1/dir2″.replace(/\/?/, “”); Rewrote the regexp in path.makePathAbsolute() that was stripping leading slash, and trailing filename/slash. This gets around the problem. Special thanks to @adambiggs for helping us test 33 iterations when trying to narrow down the cause!

Fixed form buttons no longer submit forms in Internet Explorer 8 -

Corrected corner styling issue with listview refresh on growing lists (issue #1470) – If list items were appended and the refresh() method called, the correct corners were not being assigned.

Fixed incorrectly calculated path of forms (issue #1923)- Added code to calculate whether to choose the documentUrl or the page Url in the case where an action is not specified on a form element. Fixed bug in the navigation “submit” handler where an error was being thrown if “type” was not specified.

Hitting enter in search filter now doesn’t not submit the form – Since this is a client-side filter, we want to prevent submitting the form. Thanks adamvaughan

Remove unnecessary ajax call and duplicate DOM nodes when refreshing a page with a dialog visible (issue #1913) - This was causing duplicate dialog elements inthe DOM. Thanks Sunpig!

Controlgroup now filters on visible buttons when adding first and last classes for rounded corners. If you hide the first or last button in a controlgroup and then call refresh on it, it won’t add the right classes to the newly promoted first/last button.

Removed param “refresh” sent to .controlgroup since it’s not a $.widget

Tweaked styles for select menu text running off side of list – Seen when using the custom select menus only

Updated Valencia theme for the updated check and radio styles

Fixed swatch letter typo for E button in theme CSS (Issue #1894)- it said ui-bar-d instead of ui-bar-e. . Thanks app42!

Moved collapsible sets (accordions) in docs into a standalone page for better visibility, updated section nav on other pages and index page to link to it.

Moved our form binding into the _registerInternalEvents callback, to ensure it’s not bound until after mobilinit.

Removed vclick + click combined event binding (issue #1870), which was in there as a workaround for a not-consistently-occurring bug in Android 2.1. I think the real issue is related to lack of dynamic base tag support, and that occasionally, a relative href click will use default handling in 2.1 and go where it shouldn’t (ignoring the base href). Either way, this double binding causes history problems in Safari, so I’m removing it while we search for a better 2.1 workaround.

Pinehead.tv Tutorial Videos

For a good intro on using jQuery Mobile, check out these video tutorials on Pinehead.tv. Examples include:

O’Reilly book on jQuery Mobile released

jQuery Mobile Book

A new book on jQuery Mobile from O’Reilly written by Jon Reid is now available for purchase. View book details. Description from the site:

The future belongs to mobile web apps that function on a broad range of smartphones and tablets. Get started with jQuery Mobile, the touch-optimized web framework for creating apps that look and behave consistently across many devices. This concise book provides HTML5, CSS3, and JavaScript code examples, screen shots, and step-by-step guidance to help you build a complete working app with jQuery Mobile.

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="http://code.jquery.com/mobile/latest/jquery.mobile.min.css" rel="stylesheet" type="text/css" />
<script src="http://code.jquery.com/jquery-1.6.1.min.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.min.js"></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.

 

jQuery Mobile Beta 1 Released!

Posted on by

The jQuery Mobile team is happy to announce the release of Beta 1. We’re proud of the refinements we’ve made to make jQuery Mobile faster, extensible and more compatible over the last 12 weeks and look forward to having more frequent releases as we work up to 1.0 in late summer. We’re planning on releasing a second Beta in about a month that will begin decoupling our code so you can include only the components you need, add greater extensibility to support dynamic JS-driven sites, and bring even broader device support.

Note that jQuery Mobile 1.0 will require jQuery core 1.6 as a baseline. Going forward, we’ll be supporting the two latest major versions of core but we’re starting with a cleaner baseline for launch. Here is a summary of what’s new and improved in Beta 1.

Demos & docs | Supported Platforms | Key changes | Change log | Upgrade notes | Download & CDN

Platform support: Expanded for Beta 1

jQuery Mobile is a broadly compatible HTML5 library for building web sites and apps and we’re very proud of our commitment to universal accessibility through our broad support for all popular platforms. Since we added WP7 support in Alpha 4, we’ve added support for both Blackberry 5 devices and Opera Mini in Beta 1 which dramatically increases the reach of the framework. Opera Mini had 57.9 billion page views in April 2011 alone so it’s incredibly popular, especially internationally. Both of these platforms had issues with handling the Ajax-based navigation so they receive a B grade experience with all the enhancements except for Ajax navigation.

At this stage, jQuery Mobile works on the vast majority of all modern desktop, smartphone, tablet, and e-reader platforms. In addition, feature phones and older browsers are also supported because of our progressive enhancement approach. The only notable platform still in the works is Nokia’s Symbian S60 platform and we have this targeted for Beta 2.

Our graded support matrix was created over a year ago based on our goals as a project and since that time, we’ve been refining our grading system based on real-world device testing and the quickly evolving mobile landscape. To provide a quick summary of our browser support in Beta 1, we’ve created a simple A (full), B (full minus Ajax), C (basic) grade system with notes of the actual devices and versions we’ve been testing on in our lab.

The visual fidelity of the experience is highly dependent on CSS rendering capabilities of the device and platform so not all A grade experience will be pixel-perfect but that’s the nature of the web. We’ll be adding additional vendor-prefixed CSS rules to bring transitions, gradients and other visual improvements to non-WebKit browsers in future releases so look for even more added visual polish as we move towards 1.0.

A-grade – Full enhanced experience with Ajax-based animated page transitions.

  • Apple iOS 3.2-5.0 beta: Tested on the original iPad (3.2 / 4.3), iPad 2 (4.3), original iPhone (3.1), iPhone 3 (3.2), 3GS (4.3), and 4 (4.3 / 5.0 beta)
  • Android 2.1-2.3: Tested on the HTC Incredible (2.2), original Droid (2.2), Nook Color (2.2), HTC Aria (2.1), emulator (2.3). Functional on 1.5 & 1.6 but performance may be sluggish, tested on Google G1 (1.5)
  • Windows Phone 7: Tested on the HTC 7 Surround
  • Blackberry 6.0: Tested on the Torch 9800 and Style 9670
  • Blackberry Playbook: Tested on PlayBook version 1.0.1 / 1.0.5
  • Palm WebOS (1.4-2.0): Tested on the Palm Pixi (1.4), Pre (1.4), Pre 2 (2.0)
  • Firebox Mobile (Beta): Tested on Android 2.2
  • Opera Mobile 11.0: Tested on the iPhone 3GS and 4 (5.0/6.0), Android 2.2 (5.0/6.0), Windows Mobile 6.5 (5.0)
  • Kindle 3: Tested on the built-in WebKit browser included in the Kindle 3 device
  • Chrome Desktop 11-13 – Tested on OS X 10.6.7 and Windows 7
  • Firefox Desktop 3.6-4.0 – Tested on OS X 10.6.7 and Windows 7
  • Internet Explorer 7-9 – Tested on Windows XP, Vista and 7 (minor CSS issues)
  • Opera Desktop 10-11 - Tested on OS X 10.6.7 and Windows 7

B-grade – Enhanced experience except without Ajax navigation features.

  • Blackberry 5.0: Tested on the Storm 2 9550, Bold 9770
  • Opera Mini (5.0-6.0) - Tested on iOS 3.2/4.3
  • Windows Phone 6.5 – Tested on the HTC

C-grade – Basic, non-enhanced HTML experience that is still functional

  • Blackberry4.x: Tested on the Curve 8330
  • All older smartphone platforms and featurephones – Any device that doesn’t support media queries will receive the basic, C grade experience

Not Officially Supported – May work, but haven’t been thoroughly tested or debugged

  • Nokia S60 – Targeted for Beta 2 release. A/B grade support will depend on results of device testing.
  • Meego – Originally a target platform, but Nokia decision to relegate this platform to “experimental”, we are considering dropping support.
  • Samsung Bada – The project doesn’t currently have test devices or emulators, but current support is known to be fairly good. Support level undecided for 1.0.
  • Palm WebOS 3.0 – We’re hoping to get test devices from Palm soon to start testing but have heard that rendering is quite good in 3.0

KEY CHANGES

URL bar: Now hidden in iOS and Android


One of the most common requests is to make the page transitions smoother and less jumpy and we are working hard to improve this as we move towards 1.0. There are two major items affecting the perceived smoothness: hiding the URL bar consistently and scrolling to the correct page position between transitions.

We’re happy to report that in Beta, we are able to hide the URL bar in both iOS and Android which avoids the multiple re-draws seen when the URL bar pushed down the page content, then hid later in the transition. We do this by scrolling the page by 0 pixels in iOS and 1 pixel in Android to trick the browser into hiding the bar and target this with a bit of clever feature detection. Nothing is perfect so you still may see the URL appear randomly but this should overlay the URL bar over the content briefly before disappearing but shouldn’t cause a re-draw.

Note that to accomplish the URL hiding, we’re using our custom fastclick event. There’s a small possibility that this event may interfere with jQuery plugins that bind to click events on touch devices. In these situations, you may need to tweak your code to either bind to vclick events instead of click, or set the useFastClick global config option to tell the automated Ajax handling use an ordinary click events instead. Disabling this feature will introduce a slight delay in clicking links and the URL bar will not be hidden.

Transitions: Smoother, faster scroll

If you don’t scroll the page at all and click on a link, you should see a smooth page transition with no jumps or blinks in Beta 1. However, there will be two potential situations that cause a scroll and visible blink: scrolling back to the top of the current page before a transition, and scrolling back down to your previous scroll position if you return to a page. We’ve been doing a lot of work to try and reduce or eliminate the scroll position blink, especially the need to first scroll to the top of the page before starting a transition, but it’s a tricky issue to solve across all the devices we support. We’ve minimized the speed and amount of scroll jumps for Beta 1, but still have a ways to go and will be working on refinements for future releases.

Restoring your scroll position is an important usability feature and is the expected behavior on both the web and in apps but it does introduce a small blink as the browser scrolls the viewport to the correct position and re-renders the new view. One tweak we introduced in Beta 1 is a threshold value for how far down the user needs to scroll a page before we restore their scroll position. For example, if the user only scrolled a page 50 pixels before clicking a link, it’s not worth seeing a scroll re-draw to restore that position but if they scrolled 500 pixels, it’s a huge time-saver.

By default, this scroll threshold is calculated as half of the device’s screen height, but can be adjusted in the minScrollBack config option. To eliminate the threshold, set this option to “0″. To completely disable the scroll position restore feature, set this option to infinity but remember that this may make your app much less usable, despite the smoother transitions.

Navigation core: Decoupled for extensibility

We landed a big refactor the core Ajax navigation code to allow for better extensibility for developers that are manipulating pages dynamically and plan on adding a lot more hooks for Beta 2 to make this even more powerful. Until recently, the navigation code was largely implemented as a set of nested functions within the$.mobile.changePage() function which made the code very hard to follow and extend so for Beta 1, we decoupled the navigation core into separate internal functions. Partitioning the code this way makes it easier for us to identify key points for adding extensibility hooks and makes the code easier to follow:

  • loadPage()
    • Responsible for loading a page into the DOM of a specific page container and enhancing it
  • changePage()
    • Responsible for updating the internal bookkeeping for tracking what is the current page. This includes: managing the URL stack, managing the location hash, and kicking off transitions
  • transitionPages()
    • Responsible for managing the transition between the current active page and the new page to be shown

Of these, loadPage() and changePage() methods are public. The changePage() method now takes 2 arguments: the first is required,  the second is optional. The first argument accepts a URL or a jQuery collection containing a page element as its first argument. The 2nd argument is an options object that allows the caller to modify changePage behavior. The options that can be specified are as follows:

  • transition (String, defaults to transition specified by $.mobile.defaultPageTransition)
  • reverse (Boolean, defaults to false)
  • changeHash (Boolean, defaults to true)
  • role (String, defaults to “page”)
  • pageContainer (jQuery collection, defaults to $.mobile.pageContainer)
  • type (String, defaults to “get”)
  • data (Object or String, default is undefined)
  • reloadPage (Boolean, default is false)
  • showLoadMsg (Boolean, default is true)

URL handling: Coverage for all path types

There are a number of factors involved in loading files in jQuery Mobile. The framework essentially listens for normal link clicks and form submissions and requests them through Ajax which allows us to support page transitions as the user navigates a site. Path handling within jQuery mobile is one of the most complex parts of the framework because it needs to handle the wide array of paths that a browser may encounter and seamlessly resolve the page and all it’s dependencies (images, stylesheets, scripts, etc) and also needs to work well with file:// URLs for installed applications. In Beta 1, we now cover every possible URL path type and have added robust unit test coverage to ensure we avoid regressions moving forward. When upgrading to Beta 1, no changes are needed to take advantage of these URL handling improvements.

Dynamic base tag: More robust

The Ajax navigation system loads multiple “pages” into the DOM of the starting page. Each of these pages loaded in could live in completely different directories on the server so the paths of links, forms, images, scripts and styles of each page need to be dynamically set so everything “just works”. To do this, when the initial jQuery Mobile document is loaded, the navigation code checks for an existing base tag, and if one does not exist, the framework injects one and sets its @href to path for the current document. As of Beta 1, the base tag mangement is completely re-vamped to work correctly, even in edge-case scenarios. When upgrading to Beta 1, no changes are needed to take advantage of these base tag improvements.

Page transitions: Decoupled and extensible

We’ve pulled page transitions out into a separate plugin so they can be decoupled from the navigation plugin. As part of this re-work, we’ve introduced the ability for developers to create custom transitions created with pure CSS3, or in combination with JavaScript by adding extensibility hooks to the transition system.

Pinch-to-zoom: Now restored in demos

Before Beta 1, all our demos and docs had a viewport meta tag that set “minimum-scale=1, maximum-scale=1″ which completely disabled the pinch- or double-tap-to-zoom feature in mobile browsers. We had done this originally because on iOS, there is a bug that will incorrectly scale the page when you change orientation. Here is the meta tag we used up through Alpha 4.1:

<meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1">

Disabling the native zoom features of the browser isn’t very user-friendly so we changed our meta tag in the demos and docs for Beta 1 to restore the ability to zoom the page. At this stage, we don’t think it’s worth disabling the user’s zoom feature to workaround an iOS bug that may be fixed in the near future. Since our demos are used as a template for many people so we want to set an example of the best practice for mobile web development. The new meta tag we use looks like this:

<meta name="viewport" content="width=device-width, initial-scale=1">

 

You will notice that in the Beta 1 demos & docs, you be able to pinch zoom the pages. You may also notice that the pages will zoom in when interacting with form elements on some browsers and this is normal with this viewport configuration. Since this meta tag is part of your page content, you are free to set these attributes to match the specific needs of your project so this isn’t a change to the library, just our demos.

Dynamic injected viewport meta tag: Support dropped

On a related topic, we deprecated injecting the viewport meta tag back in alpha 4 due to Windows Phone 7’s lack of support for dynamically injected viewport elements.  In Beta 1, we removed the dynamic viewport support from the codebase in preparation for beta so if you haven’t switched to writing this tag into your markup, please do that now in preparation for Beta. If you page is zoomed out to a wide width when you upgrade, you’ll need to add a meta viewport tag to each page to control the zoom level. See the boilerplate template page in the docs for an example.

Automatic toolbar back button: Now off by default

In a blog post, we outlined the reasons why we felt the feature that automatically adds a back button to the header toolbar, while good for specific situations, wasn’t really necessary for most web sites and web apps because browsers and phones already have back buttons. The response in the comments and Twitter was overwhelmingly positive to moving in this direction so for Beta 1, we landed this change.

All this really means is that the auto-generated Back button feature is off by default. It’s not going anywhere because we understand that in fullscreen browser environments or installed apps, there isn’t browser chrome or a physical back button on all platforms so you’ll want to flip this switch on in those cases.

To activate auto generated back buttons on specific pages, simply add the data-add-back-btn="true" attribute on the page container and the magic will be back. To activate this globally, set the addBackBtn option in the page plugin to true. Here is an example of how to set this:

$(document).bind("mobileinit", function() {
      $.mobile.page.prototype.options.addBackBtn = true;
 });

Note: You must include this script before the jQuery Mobile library is referenced in the head of your page for this to work. The mobileinit event is triggered immediately upon execution, so you need to bind event handlers before jQuery Mobile is loaded. Learn more about setting global config options.


Responsive design helper classes: Now deprecated

We include a set of responsive design helper classes designed to make it easy to build a responsive design that adapts the layout for various screen widths. At the time, we went with a system of dynamically appended min- and max-width classes on the body that are updated on load, resize and orientation change events as a workaround for the limitation that Internet Explorer doesn’t support media queries.

Although this technique works, it adds script overhead that we’d like to avoid as we move towards 1.0. Within jQuery Mobile, we only use these classes for a single feature: the responsive label/form layouts. This week, we re-wrote the styles for the form elements to work without the helper classes by switching to standard media queries in our CSS. Since we use media queries sparingly right now, the only change you’ll see is that at wider screen widths, WP7 won’t switch to the layout with the label floated to the left of the form element.

We understand that many developers may be using these CSS classes so we’re going to leave this code in until for Beta 1 to give everyone time to migrate to other solutions. We will be removing these classes completely by 1.0. If you want to use media queries on Internet Explorer, we recommend adding in respond.js, a polyfill script written by team member Scott Jehl that adds media query support for IE.  Post-1.0, we’re going to look into whether we should polyfill media queries as part of jQuery Mobile or continue to leave it as an optional file.

Experimental datepicker: Moved out of the official docs & repo

A while back, we took the jQuery UI datepicker and tweaked it to use the jQuery Mobile theme CSS classes as an experimental stopgap for people who really needed a datepicker. The issue with this component is it’s fairly heavy for mobile and the UI team is already re-factoring the datepicker from the ground-up so we wanted to shift this out of the official GitHub repo because it won’t be supported going forward. We will pull the new UI datepicker in once it’s finished, but that will be later this year. In the meantime, if you still want to use the experimental datepicker, it’s now available on Filament Group’s GitHub repo but note that it’s not being actively maintained. If anyone is interested in maintaining this plugin in the short-term, please let us know. You can also check out alternate jQuery datepickers like DateBox, a slick jQuery Mobile optimized date picker.

Beta 1 upgrade notes

 

Breaking Changes

  • ajaxFormsEnabled and ajaxLinksEnabled are now gone (they were deprecated for a release or two). Use ajaxEnabled to globally set auto-ajax handling.
  • Removed the dynamically-appended viewport Meta tag. Thish was deprecated in Alpha 4, and scheduled for removal in beta. jQM users must provide their own meta viewport tag in the head of jQM page markup.

Deprecations

  • The signature for changePage() has changed during this refactor you will need to update your custom code before upgrading. To ease the transition to the new signature in the short-term, we’ve added code to changePage() that maps any old signature calls to changePage() into a new call. This code will be removed before shipping 1.0.
  • $.mobile.pageLoading( done ) renamed to $.mobile.showPageLoadingMsg() and$.mobile.hidePageLoadingMsg(). Status: $.mobile.pageLoading( done ) is still in the codebase but will be removed soon. Do not use anymore.

Important Notes

  • jQuery code that binds to live click events may have issues with the new URL hiding techniques because we bind to the fastclick event (touch + mouse click). In these situations, you may need to tweak your code to either bind to vclick events instead of click, or set the useFastClick global config option to tell the automated Ajax handling use an ordinary click events instead. Disabling this feature will introduce a slight delay in clicking links and the URL bar will not be hidden.
  • Auto back button additions to toolbar are now off by default. To turn auto backbuttons on, you can set the page plugin’s autoBackBtn option to true per page, or globally via its configuration prototype. You can also use the data-auto-back-btn attribute on a page div.
  • $.mobile.defaultTransition is now renamed to $.mobile.defaultPageTransition and $.mobile.defaultDialogTransition. This is likely not a breaking change since the old configuration property, $.mobile.defaultTransition, will just be ignored.

Change log

Added utility functions $.mobile.getDocumentBase() and $.mobile.getDocumentUrl() - developers can retrieve the original base and url used when loading the document.

Added themeFilter option for listviews (issue 1790) - Available as data attribute data-filter-theme on listviews with filters enabled. Thanks adamvaughan!

Added new throttledresize special event (issue 1848 and 1422) - This prevents browsers from running continuous callbacks on resize, which we use internally for orientationchange in browsers like IE. It still ensures that a held event will execute after the timeout, so logic that depends on the final conditions after a resize is complete will still execute properly. This improves performance noticeably.

Set page min-height using availHeight or availWidth – Rather than height to fine tune height to exclude browser chrome. Also, reset the active page height on throttledresize and pageshow, eliminating some duplicate calls.

Removing item from inset list doesn’t redo corners (issue 1654) – When adjusting the list items, the corner classes went’ being properly adjusted. Thanks siromega!

Remove active state from buttons when closing dialogs (issue 1839) – Buttons would retain the active state if clicked and the dialog was re-opened.

Radio buttons in nested listviews don’t work (issue 1489) – Tweaked selectors to fix this situation. Thanks bernharduw!

Fixed a bug in IE desktop - calling scrollTop before domready was trying to access the body element before it was present. Moved this logic to domready and all’s well.

No change event triggered on multiple select when first option was deselected (issue 1579) – Custom multiple select event fixes. Thanks wtw!

Top header (and back button) of a nested list doesn’t render correctly when parent list has a thumbnail (issue 1595) – Fixed so Back button doesn’t gets clipped when there is no title

Disabled select usability issues in iOS (issue 1816) – A disabled select could be opened in iOS, but not closed due to an inportant cursor rule in the CSS.

Dialog styling and hashchange nav improvements (issue 1826) –  Style a dialog is data-role=’dialog” is set on page container and ensure that hash nav between dialogs works.

Forward page transition fix (issue 1833) - If hit the browser’s forward button in some cases, you would not see a transition.

Workaround for PhonegGap double slashes in URL – Adjusted the urlParserRE regexp to account for double slashes in the directory path to work around a PhoneGap 0.9.4.

Height issue for transitioning page (issue 1507) - Fixed the issue where buttons and other elements were sometimes showing up at 100% height during page transitions. Thanks Eddie Monge.

Allow checkboxes and radio buttons to be selected with the keyboard – The name says it all, thanks Shana Golden.

Fixed header/footer positioning in IE 7/8 – Desktop IE wasn’t reporting a scrollTop value for fixed headers/footers—’window’ is now provided as a fallback in the event that $(document).scrollTop() reports zero. Thanks Mat Marquis (wilto).

Select menus now work in Firefox Mobile (issue 1626) – Changed the hiding mechanism for invisible native selects so that they work in Firefox Mobile.

Removed the ajaxLinksEnabled and ajaxFormsEnabled settings – These were deprecated in a4 and scheduled for removal. Automated link and form ajax handling can still be globally disabled via the ajaxEnabled option.

Add new focus event to show the clear button on search textbox when an item is pasted directly without a key event to search text box. Thanks joshiabk

Listview filter speed improvements (issue 1477) - We made a number of changes to improve the responsiveness of the filtering mechanism which is especially helpful on longer lists. More tweaks planned for the future. Thanks nsaleh

Phonegap: Pages with data-ajax=”false” on form fail to load (issue 1580) - In the $.ajax() callback, we look for elements with @href, @src, and @data-ajax=”false” elements, the code then assumes that matching elements will have either @href or @src, which of course forms don’t … they have @action … so the code throws an exception because thisUrl is undefined. Reworked the code to handle action and check to make sure we have an attribute and url string before attempting to use them.

Base tag regression fixed (issue 1508) - This change sets the base tag properly on page load and page changes, corresponding with the recent change to absolute path hash urls. Images and other assets will direct relative to the document in which they reside.

Can’t load file:// pages (issue 1578) - The change caused the base tag to be reset to file:// (literally with no path). All that was missing was a small tweak to base.reset() to use the new initialPath variable instead of docBase.

Grouped radio buttons with long labels don’t ellipsis (issue 1419) - Fixed grouped radio buttons with long labels so they wrap to multiple lines. Thanks gseguin!

Regex breaking Firefox >3.6 (issue 1514) - Tweaked regex to make Firefox happy. A quick bit of Date()-based benchmarking showed an improvement from ~4.5 seconds to 3ms in Firefox 3.6. The stock Android browser on my Galaxy Tab went from ~3.6 seconds to 1ms. Thanks MaxThrax

Radiobuttons can’t be selected once they are selected, then de-selected (issue 1532)Fixed by using  jQuery attr accessor instead of expando to guarantee consistent values.

Regex breaking Firefox >3.6 (issue 1514) - Fixed by Remove greedy matches from start and end of regex – there’s no need for them, and they cause immense slowdown (on the order of 3-4 seconds on medium-size pages loaded via ajax). Thanks Paul Nicholls!

Fixed base tag support (issue 1508) - This change sets the base tag properly on page load and page changes, corresponding with the recent change to absolute path hash urls. Images and other assets will direct relative to the document in which they reside.

Can’t load file:// pages (issue 1578) - Fixed a regression that caused the base tag to be reset to file:// (literally with no path). All that was missing was a small tweak to base.reset() to use the new initialPath variable instead of docBase.

Tops of pages clipped after returning from a dialog (issue 1461)
If you had scrolled down on a page, opened a dialog, then closed it, the page height was getting clipped off in iOS due to the timing of when we were placing focus back on the page.  Solution: Delayed the setting of focus till after the scroll position is restored.

Active class not being removed correctlyIf a link had an null or “#” value for the href, the active class wasn’t being removed. Modified the vclick handler code in navgation.js so that it doesn’t place the ui-btn-active class on any links meant for interactivity. Removed the return false in the vclick handler of collapsible and replaced it with a preventDefault().

Errors when trying to delete DOM elements (issue 1492) - Thanks @brukhabtu

Collapsible block prevents page scrolling on iPhone 4 (issue 1157) – Fixed events that prevented scrolling when interacting with collapsibles

Bad scroll performance since A4 on iPhone 3G (issue 1407) – Touch event tweaks for smoother scrolling on older iOS devices

Adding items to listviews on a4.1 is too slow (issue 1424) – Optimizations to listview rendering code

Download

We provide CDN-hosted versions of jQuery Mobile for you to include into your site. These are already minified and compressed – and host the image files as well. It’ll likely be the fastest way to include jQuery Mobile in your site.

CDN-Hosted JavaScript:

CDN-Hosted CSS:

Copy-and-Paste Snippet for CDN-hosted files (recommended):

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0b1/jquery.mobile-1.0b1.min.css" />
<script src="http://code.jquery.com/jquery-1.6.1.min.js"></script>
<script src="http://code.jquery.com/mobile/1.0b1/jquery.mobile-1.0b1.min.js"></script>

 

If you want to host the files yourself you can download a zip of all the files:

ZIP File: