jQuery Mobile Team Meeting – Jun 30 2011

##Areas of focus right now:

###Cross-platform page transitions (Ghislain)

###PushState implementation: In the works (Scott)

Our approach: this sits on top of the current hash system and when hashchanges come through, if pushstate is supported, it replaces the hash with a better url but will fall back to tracking haschchange in the browsers that don’t support pushstate.

It’s working quite well so far in Firefox 5, Chrome, Safari, and Opera latest. We need to do more testing on mobile devices.

Unfortunately iOS gets pushstate wrong (support is true, but it only lets you set pushstate based on a user action, like in a click callback) which doesn't work for us, since we set hash based on all sorts of conditions, including programmatically with $.mobile.changePage. If we strictly used history.pushState when it is supported, iOS would really break because the URL just never update. Instead, we use replaceState to react to hash changes which ensures that iOS is excluded from this feature until it’s properly supported. So iOS still gets hash urls, despite its claimed pushState support (this isn't fixed in iOS5 either).

Some URLs will always be hash-based such as dialogs and nested lists which lines up well with how hashes traditionally work anyway. When it's a dialog or a nested list page url, we’re only adding the relavant part to the hash.

We’ll need to do a lot of work on our unit tests to fork it to either look at the URL or hash because this feature won’t be supported in many places for the near term.

###XSS fix (Ghislain has a fix, jaubourg to review)

###IE/WP7 - gradients and rounded corners = trouble

Should we just drop all -filter rules and go with flat color for IE? Even with these in not, IE and WP7 don’t show gradients (need some hacks for it to work), Mango bleeds out corners if combined with a -filter gradient. IE10 will support standard CSS gradients. I’d rather add support for Opera gradients because it works and has greater reach.

##Beta 1 - blog post

###Beta 1: Issues with vclick for handling links

In Beta 1, we switched to using our custom vclick events in Beta 1 for handling Ajax links to improve responsiveness and because this change really helped to hide the URL bar consistently on the iPhone and Android phones. The vclick feature is a custom synthetic event that normalizes events by listening for touch and click events. It works at the document level and looks for duplicate events on the same target and will go with the one that bubbles up first and cancels the duplicate event.

Even though we did quite a bit of testing before landing this for Beta 1, we began to hear feedback that this change was causing some significant issues out in the wild including:

  • Multiple click events causing navigation and form element issue – In certain situations, when tapping an element, tap/click events seem to fire twice on links and is due to edge cases where the target of the touch event and mouse event don’t match due to how the browsers calculate tolerances for these events. This is most pronounced on Android 2.1 but affects most WebKit-based browsers when you tap near the edge of an element.

  • Click handlers in custom scripts didn’t “work” anymore – if a script binds only to click events on the document, the vclick feature could interfere because the touch events may supercede these click events so it won’t appear to trigger.

  • Disabling vclick globally didn’t work – To compound the issue, we had recommended using a new $.mobile.useFastClick option to disable the vclick feature globally but there was an issue with this option in Beta 1 that prevented this from working as designed.

###Our solution: Roll back from vclick to click globally

Based on a lot of detailed testing and analysis, we’ve decided to roll back to using standard click events on links instead of vclick because it’s the only reliable way to support all our target browsers. If you test on the latest builds with this change integrated, things should work reliably again. There are two important things to note in this change:

  • URL bar hiding isn’t quite as slick as in Beta 1, but link handling is obviously much more important. The good news is that there is still a significant improvement from Alpha 4.1: although URL bar may appear briefly it overlays the page instead of pushing down content and causing a re-draw blink. We methodically tried every technique we could to keep the URL bar hidden but there is unfortunately a Safari bug (even in the latest Beta 2 of iOS 5)

  • The useFastClick option is now removed in the latest code because we’re not using vclick globally anymore on links and don’t recommend doing this going forward. We hardly knew ye…

##Beta 2 - Planning and prioritization