Ajax navigation moving along
Our Ajax navigation re-write in still in-progress in a branch, but here are some of the key things we’ve done this week:
- Broke out nested functions from changePage() to improve readability/understanding.
- Changed signature to changePage() so that it uses an options structure.
- Removed differenciation between form submit and loading. It’s all the same. Now there is a generic flag/option you can pass that is forceLoad: true which does the same thing for forms.
- Replaced $.mobile.defaultTransition with $.mobile.defaultPageTransition and $.mobile.defaultDialogTransition.
- Performance fix to prevent unnecessary crawling of the entire document.
Responsive design helper classes: Deprecated for beta
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 after the first beta 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.
Toolbar back button: Relevant on the web?
When we first introduced jQuery Mobile, one pattern we adopted was the “back” button in the header bar because it’s a standard app convention. We went so far as to include a back button on every page we Ajax in automatically. However, as time has gone on, we’ve been wondering if this is still a good idea for a few reasons:
A web app runs in a browser that already includes software and/or hardware based buttons for navigating forward and back in the history stack so a button in the header is redundant and may not used as much as the native controls which have the benefit of habitual use. A hardware back button is standard on all Android, WP7 and Blackberry devices and we’d bet most users on those platforms prefer to use the hardware button. Both iOS and Palm WebOS don’t have hardware buttons, but both have a persistent back button available in the browser chrome at all times. The only time a back button is critical is in a fullscreen iOS or WebOS app.
Compounding our issues with the automatic back button is it’s seemly unpredictable behavior. When we first added this feature, we actually had a bug that added it to every page unless you shut off the feature or had a button in the lefthand slot in the header. We eventually fixed this so the back button was only added if jQuery Mobile loaded a page through Ajax so we could know that the back button would go back to another jQuery Mobile page and not some random site in your history stack. However, this caused a lot of confusion because the back button would “disappear” when a page was refreshed or when you linked to a page with the data-ajax=”false” attribute.
Because we originally built the demos and docs pages with the auto back button as the only navigation feature, a lot of people followed this pattern. In hindsight, we think this is less than ideal because a web site or application should have some form of persistent navigation. For any web site or web application that will be consumed primarily through the browser, we recommend following all the normal web conventions for navigation:
- At a minimum, provide a link back to the home screen, either via a linked logo or home button, like we do in the demos & docs so a deep link to a page isn’t a dead-end
- Consider adding a way to access other primary navigation, either via a simple navbar or menu
- Consider providing a global search box if available on every page
- Add additional navigation links at the bottom of pages to improve flow flow one page to another. It’s always easier to access navigation at the end of a long page than at the top
Our current plan is to shut off the automatic back button feature by default for beta and are considering whether to keep this feature in for 1.0. Let us know your thoughts, we’re listening.
Submitting an issue? Some tips
To help us resolve issues in the Git tracker as quickly as possible, here are a few critical things that every ticket should have:
- First test to see if this is still an issue in the latest Git build because we’re constantly fixing bugs after a release. Include our latest JS and CSS files in your project to see if we’ve already fixed it. If it can be reproduced in the demos and docs, simply view the latest on the /test/ directory:
http://www.jquerymobile.com/test/ - Always specific the platform and version if it’s in the native browser: Ex. iPhone 3GS, iOS 3.2
- If you see an issue with a 3rd party browser, specify that in addition to the device info. Ex: Firefox mobile 4.0b3 running on HTC Aria running Android 2.2
- List out the detailed steps and conditions needed to reproduce the bug
- Don’t paste huge chunks of code into the issue ticket. Instead, post a demo page on an online code sharing site like JS Bin or jsFiddle or in a Git repo so we can demo the page and view the code easily. For a head start, use this JS Bin as a template that includes a live link to the latest build: http://jsbin.com/ukewu3/edit
Notable changes this week
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. This may not cover new path situations Kin has documented, but it does fix the regression so things work as they did before the change. Tested in non-base supporting browsers to verify it works there too. The following page should have an image in the content, verifying the fix
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.
Listview theme swatch D issue when clicked (issue 1624)
When an item in a listview with the D swatch of the default theme is tapped or clicked, the btn-down class creates a square border and looked chunky. Fixed by removing extraneous style rules. Thanks epsd
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
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.
