Development Update – Week of April 21, 2011
Attending: Todd Parker, Scott Jehl, John Resig, Kin Blas, John Bender, Eddie Monge, Steven Black
Project communication
We’re going to try to post a summary of our weekly meeting here on the wiki and on the jQuery.org site so everyone can see what we’re up to on the project.
Going forward, all communication and meetings will take place on IRC channels for better transparency and to gain input from the jQuery Mobile community. Core dev team discussion is now in #jquerymobile-dev. For help with jQuery Mobile, please use the #jquerymobile or #jquery channels on freenode.net. Weekly jQuery Mobile team meetings will happen on the #jquery-meeting IRC channel on freenode.net every Tuesday at 2:00pm EST/11am PST.
Key issues we’re tracking now
Tops of pages missing after returning from a dialog in Safari and iPhone
https://github.com/jquery/jquery-mobile/issues/1461
https://github.com/jquery/jquery-mobile/issues/1457
This issue is tied to recent focus management changes. Solution noted in comments: we just need to bind to the silentscroll event for when we set focus. Kin will try to land this ASAP.
Ajax = issue re: relative paths
In A4.1 links referencing parent directory with the `../` syntax break some ajax calls. Needs testing with the forced absolute paths introduced post A4.1. Closed and created new issue: https://github.com/jquery/jquery-mobile/issues/1171
Active state stickyness issues
Buttons in jQM have 4 states: normal, hover, focus, and down (pressed) which is a bit different from the link’s :hover and :active states. Our active state is not parallel to a link’s :active, instead it’s meant to be more like and “on” or selected state that is only needed for stateful buttons or special cases (like lists) where we want to have an “on” state.
Proposed change: only set the active class on a button if we know we’re navigating so any null or # links will get the down state but not active.
The “active” class name is a bit confusing because of reasons outlined above, may be worth changing if we can find a much clearer name. Look here for synonym ideas: http://thesaurus.com/browse/Active
Navigation: changepage
• Lengthy discussion on how to proceed.
• Goals: less procedural, separate things out for readability, tightly coupled thru scoping on purpose,
• plan our re-factor on the wiki ahead of time, add high-level tests before re-factoring
• Tangent on initial conditions for tests.
• Pulling transitions from changePage(). An easy get?
• Navigating to self… legitimate in generated pages?
• Making isExternal smarter.
• Moving arguments over to a hash, rename changePage so it can act as a proxy to new one?
• Page container concept: pave the way to multi-panel tablet, handles transitions between pages in the DOM
• Followup with history.js @ https://github.com/balupton/History.js
• Kin will be available to lead the charge on this and everyone else will plug in. First step is to keep filling out the navigation mapping and planning wiki pages here and here.
Recent commits
Fix from @brukhabtu for issue 1492 – Errors when trying to delete DOM elements.
Check for existence of the bindings object before attempting to use it. Apparently jQuery core strips off any data bindings of an element before calling teardown on it to remove special event handlers.
Fix for issue 1157 – Collapsible block prevents page scrolling on iPhone 4
When we switched to virtual mouse events, I just did a straight translation of the code that existed which basically did the collapse/expand on mouseup. In order to factor in scrolling, I needed to move that code into a vclick handler and stopPropagation() and preventDefault() to make sure the button doesn’t activate.
Fix for 1407 – Bad scroll performance since A4 on iPhone 3G
– Modified vmouse code so that it uses $.data() instead of $().data() which is significantly faster.
– Modified the navigation and buttonMarkup code so they stop using live(). The vmouse code triggers several events during the touch events, which in turn causes the underlying event code to call $.closest() with the selector used during the live() call to figure out if the event should be handled. This turns out to be very expensive, so instead, we now just bind directly to the document, and walk the DOM manually to figure out if we should handle it. This is much faster since we are avoid triggering multiple nested function calls.
Fix for Issue 1424 – Adding items to listviews on a4.1 is too slow
– Modified _itemApply() to make use of item.children() and filters. Also got rid of some unused code.
– Convert .each() in refresh() to a loop.
– Cache some $list.jqmData() values so we don’t do it for each list item.