###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
###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.