##Navigation re-write status update
- Decoupling and cleanup (Kin)
- 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)
- ideas: https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation.js-A4.1-extensibility
- 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:
- Test the latest with Ajax disabled here (works fantastic in mini and BB5)
- 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?)
- Dialogs (support data-role=”dialog” on pages?)
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