Expose touchTracker as a protected variable of pointerEvents.

[sbrunot]

This allows implementing the following pattern to drag and drop an item in a list on touch devices:

Items are moved within the list using drag and drop. When an item is “pressed” (pointerdown event) for more than X seconds without moving, it is grabbed, at which point it can be dragged up and down the list by moving the pointer. When it is dropped, the location of the drop defines where the item should be moved within the list. If an item is "pressed" less that X seconds and the user moves the pointer, the item is not grabbed and the list scroll as usual. Example of an application that implements this pattern: weather app on iOS.

To implement this pattern using pointer events, one need to be able to change the default touch action after the initial pointer down event: accessing the touchTracker allows to do this.

[seb-pereira]

Although it is possible to open the API in order to give the control back to the application, I see some limitations to the current solution:

1. Works only on platforms that support Touch Events and not native Pointer Events. In particular, it won't work on desktop browsers using a mouse, or on a Windows Tablet using a touch screen.
2. May not work on platforms that support touch-action CSS with Touch Event (on a mobile device or desktop browser using a touch screen). touch-action CSS is supported on Chrome 35+ and on Firefox behind the flag layout.css.touch_action.enabled (not enabled by default).

Note also that Windows Phone 8.1 should receive an update of IE11 to support Touch Events. It is currently available on Windows Phone 8.1 Preview for Developers. There is a possibility that the current solution won't work because (for the same reasons as 2.).

[sbrunot]

@seb-pereira what do you mean by "the current solution" ?

[seb-pereira]

I meant the solution for this requirement: how to allow user to hold and drag a list item when the list enforces native scroll (with touch-action giving control to the browser).

[sbrunot]

The solution is currently working on:

• Chrome 36
• Firefox 31
• Safari 7
• iOS Safari 7.x
• Android 4.3 and 4.4 stock browsers

Do we have an alternative solution to implement this feature using pointer events ?

[seb-pereira]

I am aware there are limitation for us regarding Pointer Events to implement this kind of feature.

The reason why I highlighted the limitation is because we need to think about ways to cover all platform. Following the Pointer Event specification is not a requirement if it is a limitation to implement user requirements. Maybe there are solutions that will imply to NOT strictly follow the PE specification, maybe not, I do not know and I make no assumption. I suggest to open a deliteful issue ("move list item?") to address this what do you think?

In the meantime there is this dpointer issue to track the known limitations, discuss and decide if/how dpointer should answer to those limitations.

[sbrunot]

I thought we discussed that already, hence this pull request. One potential solution would be NOT to use pointer events for this pattern, but currently you cannot decide to use pointer events on a page except for one component (the list with movable items, in my example). Moreover, not using pointer events is only possible on platforms that do not use pointer events natively, as you highlighted... So I don't see many alternatives here... ?

[seb-pereira]

No problem for the pull request, I'll address it after I push other changes.

Yes we discussed about issues and as you mention there is one potential solution. Let's just track our discussions and continue our investigations in a dedicated issue and not in this PR.

[seb-pereira]

I pushed this branch to work on this. To integrate with MovableItems.js:

• require module dpointer/handlers/touch (as touchAdapter for example)
• replace your FIXME block by touchAdapter.preventTouchAction(pointerId)

Since dpointer now supports native CSS touch-action (#30), this hack won't work on Chrome 35+.

[cjolif]

I pushed this branch to work on this.

We said we want to think about a solution that would cover all the cases where we do have issues right? So that one might not be our final solution? Do we already have a document listing the various limitations we face or we expect to face with dpointer?

[seb-pereira]

@cjolif That is definitively not a solution, that is why I'd like to work that path (hacking touch-action when listening on Touch Events) on a dedicated branch and not on master.
What I'd like is:

• close this PR
• use this dedicated branch to share experimentations on "touch-action prevention"

There is a dpointer issue #27 about potential limitations, but what we miss is a discussion about the feature we want, the current limitations and eventually other solutions, whatever the impact on dpointer.

@sbrunot Where do you want to share about this feature requirements/limitations, is this one ibm-js/deliteful#232 ok?

[sbrunot]

ibm-js/deliteful#232 is fine with me. But I won't understand why you would close this issue instead of putting it "on hold" ? My understanding is that you guys want to think about a better solution: let's keep this one open and close it when a better solution is found. What do you think ?

[seb-pereira]

why you would close this issue instead of putting it "on hold" ?

Because this is not an issue, this is a PR on master to introduce a feature which targets only a limted subset of platforms.

As I said I am ok to work on experimentations on a dedicated branch (https://github.com/seb-pereira/dpointer/tree/preventTouchAction), and if/when we are ok on a solution we can merge into master.

In the meantime, ibm-js/deliteful#232 should handle discussions/decisions about the feature requirement(s) and solution(s). This may eventually lead to open dpointer issues/PRs.