##Navigation re-write status update

• Decoupling and cleanup (Kin) - BETA 1
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation.js-A4.1-structure
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-changepage-outline
  • Changes landed this morning:
  • https://github.com/jquery/jquery-mobile/commit/368d3e55b44b0c41debecce4fa72e37898637bb5
  • open question:
• Improved URL handling (Kin) - BETA 1in-progress, test written, code changes in progress
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation-paths
  • Note some great ideas/abstractions in https://github.com/mtrpcic/pathjs
• Extensibility hooks (who?)
  • ideas: https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation.js-A4.1-extensibility
    • Of note: Some of our hooks (pagebrforehide and pagebeforeshow) and (pagehide and pageshow) occur at the same juncture.
    • We have clear junctures that could be hooked
    • Given we are so URL-centric, need URL hooks (agreed generally at the last meeting)
• Page caching on/off flag (Steven) - BETA 1
  • Add a simple "don't cache" flag per page via a new data-cache attribute on the page div to tell framework to re-load it if shown again, default is “true” (re-use the page) but you can set data-cache="false" to tell the framework to re-load everytime it’s viewed
  • Issue: https://github.com/jquery/jquery-mobile/issues/1554
• Memory management for the DOM (Steven)
  • How to keep the DOM from getting too big? Add a new global configuration option to set the max number of pages to keep in the DOM at once.
  • After discussing this, we don’t want to include anything hard-coded in the framework. We want to support a plug-in system that allows developers to write a range of different memory and DOM management tools because there isn’t a single “right solution.
  • Steven Black will take a crack at writing a plugin to illustrate this system
  • Issue: https://github.com/jquery/jquery-mobile/issues/1555
• Same-page as a navigation target (Kin)
  • Some developers are opting to repeatedly re-use the same container as a target for generated markup. Think self-referent pages as a desirable feature design-wise (Steve to elaborate).
  • https://github.com/jquery/jquery-mobile/issues/1643
• Page show initial focus: can we handle this better? (Scott)
  • We need to have focus brought to the top of the current page on transition for accessibility and keyboard/focus-based navigation
  • Scott Jehl will create a wiki page with suggestions
  • Related issue: https://github.com/jquery/jquery-mobile/issues/1560
• Transitions: how to smooth out, eliminate blinking and jumpiness (Kin)
  • Kin will tackle this after URLs
  • https://github.com/jquery/jquery-mobile/issues/455
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-Transition-dependencies
• Move most of our widgets move to self-invocation via binding to pagecreate
  • Need to document on the wiki
• Use history push or replace state (Scott)
  • We need to have an abstraction our paths cross through so that folks can formulate the URLS they place in the location
  • May be that it sits lightly on top of our hash handling. Maybe that's fine. Like... where we bind to hashchange, we'd also bind to popstate, and we could use replaceState right there to swap the hash out
• Docs update this weekend
  • New template will be in beta
  • Content architecture outline put in place
  • Getting started guide implemented (Ray’s version)

##Targeting Ajax navigation and animated page transitions (Scott) Currently in jQuery Mobile, if a browser supports media queries or is Internet Explorer, we enhance the page to the full experience, including Ajax-based navigation for animated page transitions. The issue we’re seeing now is that there are browsers that support all the advanced enhancements but don’t properly track hash changes as history stack events so the back button is essentially broken on both Blackberry 5 and Symbian. Opera Mini also has issues with the Ajax navigation system because of the way it’s proxy-based rendering works.

###Suggested action:

• Find object/feature detection ways to exclude the following browsers from the Ajax Navigation but still give them the enhanced experience otherwise (Scott)
  • Blackberry 5
  • Opera Mini
  • Nokia S60
• Issue to exclude here:
  • https://github.com/jquery/jquery-mobile/issues/1644
• Test the latest with Ajax disabled here (works fantastic in mini and BB5)
  • http://filamentgroup.com/clients/om/
• With Ajax off, we need to tweak all plugins that rely on Ajax. This needs to be done anyway because this feature cna alwasy be turned off globally but we have some dependent plugins:
  • Dialogs (support data-role=”dialog” on pages?)
    • Support dialog role issue: https://github.com/jquery/jquery-mobile/issues/1094
    • Dialog theme issue: https://github.com/jquery/jquery-mobile/issues/1375
  • Nested lists (flat list but indent child list items?)
  • Large (full page) select menus (just use native menus?)

##Navigation re-write status update

• Decoupling and cleanup (Kin)
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation.js-A4.1-structure
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-changepage-outline
• Improved URL handling (Kin)
  • in-progress, test written, code changes in progress
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation-paths
  • Note some great ideas/abstractions in https://github.com/mtrpcic/pathjs
• Extensibility hooks (who?)
  • ideas: https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation.js-A4.1-extensibility
    • Of note: Some of our hooks (pagebrforehide and pagebeforeshow) and (pagehide and pageshow) occur at the same juncture.
    • We have clear junctures that could be hooked
    • Given we are so URL-centric, need URL hooks (agreed generally at the last meeting)
• Page caching on/off flag (who?)
  • Add a simple "don't cache" flag per page via a new data-cache attribute on the page div to tell framework to re-load it if shown again, default is “true” (re-use the page) but you can set data-cache="false" to tell the framework to re-load everytime it’s viewed
  • Issue: https://github.com/jquery/jquery-mobile/issues/1554
• Memory management for the DOM (who?)
  • How to keep the DOM from getting too big? Add a new global configuration option to set the max number of pages to keep in the DOM at once.
  • After discussing this, we don’t want to include anything hard-coded in the framework. We want to support a plug-in system that allows developers to write a range of different memory and DOM management tools because there isn’t a single “right solution.
  • Steven Black will take a crack at writing a plugin to illustrate this system
  • Issue: https://github.com/jquery/jquery-mobile/issues/1555
• Same-page as a navigation target (Kin)
  • Some developers are opting to repeatedly re-use the same container as a target for generated markup. Think self-referent pages as a desirable feature design-wise (Steve to elaborate).
  • https://github.com/jquery/jquery-mobile/issues/1643
• Page show initial focus: can we handle this better? (Scott)
  • We need to have focus brought to the top of the current page on transition for accessibility and keyboard/focus-based navigation
  • Scott Jehl will create a wiki page with suggestions
  • Related issue: https://github.com/jquery/jquery-mobile/issues/1560
• Transitions: how to smooth out, eliminate blinking and jumpiness (Kin)
  • Kin will tackle this after URLs
  • https://github.com/jquery/jquery-mobile/issues/455
  • https://github.com/jquery/jquery-mobile/wiki/Refactor:-Transition-dependencies

##Targeting Ajax navigation and animated page transitions (Scott) Currently in jQuery Mobile, if a browser supports media queries or is Internet Explorer, we enhance the page to the full experience, including Ajax-based navigation for animated page transitions. The issue we’re seeing now is that there are browsers that support all the advanced enhancements but don’t properly track hash changes as history stack events so the back button is essentially broken on both Blackberry 5 and Symbian. Opera Mini also has issues with the Ajax navigation system because of the way it’s proxy-based rendering works.

###Suggested action:

• Find object/feature detection ways to exclude the following browsers from the Ajax Navigation but still give them the enhanced experience otherwise (Scott)
  • Blackberry 5
  • Opera Mini
  • Nokia S60
• Issue to exclude here:
  • https://github.com/jquery/jquery-mobile/issues/1644
• Test the latest with Ajax disabled here (works fantastic in mini and BB5)
  • http://filamentgroup.com/clients/om/
• With Ajax off, we need to tweak all plugins that rely on Ajax. This needs to be done anyway because this feature cna alwasy be turned off globally but we have some dependent plugins:
  • Dialogs (support data-role=”dialog” on pages?)
    • Support dialog role issue: https://github.com/jquery/jquery-mobile/issues/1094
    • Dialog theme issue: https://github.com/jquery/jquery-mobile/issues/1375
  • Nested lists (flat list but indent child list items?)
  • Large (full page) select menus (just use native menus?)

link Restore user zooming capability

• Right now, all our demos and docs have this meta tag:

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

The issue is that the minimum-scale=1, maximum-scale=1"portion completely disables the pinch- or double-tap-to-zoom feature which isn’t very “webby” so we’re going to change our meta tag to set a better example of how to code a page in jQuery Mobile. The meta tag is part of the user’s page content so this isn’t a change to the library per-se, but our demos are used as a template for many users so this is important to evangelize.

• The proposed meta tag we’ll use will look like this:

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

On iOS, there is a bug that will incorrectly scale the page when you change orientation which is the reason why we originally used the current meta tag configuration, but 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. A bug was submitted to Apple by Filament Group, and there’s a description here: http://filamentgroup.com/examples/iosScaleBug/

JavaScript can be used to manipulate this tag dynamically but this approach is far from fool-proof and causes some performance issue so we want to start with the simplest option (leaving the browser feature untouched) and think about alternatives to improve this for 1.0. Jeremy Keith has a great article on this topic: http://adactio.com/journal/4470/

Ticket for this change here: https://github.com/jquery/jquery-mobile/issues/1645

Fix provided here: https://github.com/jquery/jquery-mobile/commit/8ba4c27300da72f5792c98a6aeb53e2f2fd4b02c

and here: https://github.com/jquery/jquery-mobile/commit/04cb9c185040994265ffbd3e40a9ab2cb3ab1dbb

##Remove dynamically injected viewport meta tag

This was deprecated in alpha 4 due to Windows Phone 7’s lack of support for dynamically injected viewport elements. In the end, we think this should be in the page to start anyway, so we’re recommending that users of jQuery Mobile write the meta viewport tag into the head of their page (with content=”width=device-width, initial-scale=1”).

Fix here: https://github.com/jquery/jquery-mobile/commit/adf3808e842677feb23e9d1102c7203ab82a42a3

##Git repo size

The jQuery Mobile repo's large and it may be due to obsolete branches.

• 113.2M on disk here, of which 103M is in the .git/objects folder.
• Use git prune and git gc to cleanup? On my local fork, git prune -v -n (-v to just report) reports nothing = no unreachable objects in the jQuery Mobile repo. So let's consider deleting obsolete remote branches.
• ftp://82.96.64.7/pub/software/scm/git/docs/v1.5.1.4/git-prune.html
• http://www.kernel.org/pub/software/scm/git/docs/git-gc.html
• [git gc] on jQuery Mobile saves 2M on the 113M used locally. Hardly worthwhile. THEREFORE, looks like deleting obsolete remote branches is the next step.

##Transition encapsulation and packaging (current state: fuzzy idea)

• (From Steve) Currently we have jquery.mobile.transition.js package (for css3 transitions) and jquery.mobile.navigation.js acting as a transition “god object” (as it were). Possibly better: navigation triggers at the appropriate junctures, and transitions, as a self-sustained independent package, listens and acts, or not. Acid test: navigation would know nothing about transitions.

###Probably good: Audit, eliminate setTimeout() wherever possible

• Expecting that some of these can be engineered with $.deferred instead.
• Currently we have 15 setTimeout() calls in Master.
  • 2 in core.js
  • 2 in event.js
  • 2 in footer.js
  • 3 in select.js
  • 1 in textinput.js
  • 1 in hashchange.js
  • 3 in navigation.js
  • 1 in vmouse.js

###Datepicker fixes

• It’s experimental and temporary so we don’t want to focus too much time on updating
• What is our longer-term plan for this? Current UI version is too heavy for mobile
• Coordinate with UI team on what new codebase to standardize on
  • Re-write already in progress, planned for UI 2.0 release: http://view.jqueryui.com/datepicker/datepicker-rewrite/index.html
  • Calendar vs. a spinner/grouped select style picker. See: http://dev.jtsage.com/jQM-DateBox/
• Near-term, make small fixes to keep people happy?
  • Team consensus is to pull the datepicker from experiements because it’s not our direction and is taking time to triage/support
  • Potentially move as a demo into a non-project repo (Filament Group’s?)
  • Pull this in? https://github.com/jquery/jquery-mobile/pull/1543, in particular https://github.com/ofri/jquery-mobile/commit/28eddbbe91737008ccb36ea177418a675e9196d2 within it.

Outcome: Looks good, but we need tests.

###Navigation Extensibility:

• https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation.js-A4.1-extensibility
• A solid philosophy suggestion for hooks:
  • Events trigger, or call methods, always.
  • Conditional pre-hook the events (@ top)
  • Post hook methods (@ bottom)
• Currently some of our hooks are at the same juncture. These are effectively the same hook.
  • Example: beforehide and beforeshow are separated by 2-lines, and pagehide and pageshow are separated by 2-lines
• URL hooks (upon get especially) are probably critical things to add.
• Not documented in the wiki yet: authoritative user gestures like swipeleft or swiperight; ability to override any pre-specified transitions at that juncture.
• Not really a hook, but listed on that wiki page: allowing re-loading the same page including transition for apps that munge the same target container over and over.

###Pull: Input/selects with dots in with ID

• https://github.com/jquery/jquery-mobile/pull/1522#issuecomment-1131327

###Opera Mini: ajax and scrolling issues

• The problem: Opera Mini prior to V6 times-out after 2.5 seconds. See Issue 1276. https://github.com/jquery/jquery-mobile/issues/1276
• One notion is the progressive enhancement crutch is expensive for Opera Mini because we do a lot of expensive DOM insertions and manipulations that, in the end, never render anyway. A link is never a button or a bar when rendered in Opera Mini; it stays a simple link. Therefore maybe we should option-out of expensive markup, especially DOM insertions, transitions, and some setTimeout() kluges in some key situations like Opera Mini.
• Another notion: drop Opera Mini which is expensive in terms of the wider mission for jQuery Mobile.

###Targeting Ajax navigation and animated page transitions

Currently in jQuery Mobile, if a browser supports media queries or is Internet Explorer, we enhance the page to the full experience, including Ajax-based navigation for animated page transitions. The issue we’re seeing now is that there are browsers that support all the advanced enhancements but don’t properly track hash changes as history stack events so the back button is essentially broken on both Blackberry 5 and Symbian. Opera Mini also has issues with the Ajax navigation system because of the way it’s proxy-based rendering works.

Due to these limitations, we’re currently exploring how to better target Ajax navigation only to a subset of capable browsers because the animated page transitions that Ajax enables seems like a “nice-to-have” enhancement that we should layer on only if confident we won't negatively impact the user experience. We don’t believe that using user agent detection is a sustainable way to make this divide so we’re investigating feature-based detection to allow us to only opt only fully capable browsers into the Ajax navigation system.