Opened 11 months ago

Last modified 6 months ago

#17192 assigned feature

Adding Dojo.pointer to expose pointer events as a development model

Reported by: axemclion Owned by: seb
Priority: undecided Milestone: 2.0
Component: General Version:
Keywords: Cc: cjolif, pruzand, seb
Blocked by: Blocking:

Description

Dojo.touch currently exposes touch like API and covers both touch and mouse events. The pointer events specification (link) wraps different input methods into a single way to listen to events. It also exposes other properties like input type, tilt, etc. Pointer events support these multiple input methods using a single event listener and also get details about the exact input method that caused the event to be fired.

The code would look like

require(["dojo/pointer", "dojo/on"], function(touch){
  on(node, pointer.down, function(e){
  });
});


The touch-action CSS property also needs to be respected.

Change History (29)

comment:1 follow-up: Changed 11 months ago by bill

I was hoping for some more detail, since dojo/touch also "wraps different input methods into a single way to listen to events... supporting these multiple input methods using a single event listener". I assume the link you mean is http://www.w3.org/TR/pointerevents/, so AFAICT the difference between dojo/pointer and the current dojo/touch is:

  • different names for events (pointer.down instead of touch.start, etc.)
  • expose properties like input type, tilt

Sounds like #16944 is not addressed by this ticket?

comment:2 Changed 11 months ago by cjolif

  • Cc cjolif added

comment:3 Changed 11 months ago by cjolif

Bill, I guess another difference is that it should transform "webkit" events with multiple touches into several pointer events as well? I don't think dojo/touch is doing that?

comment:4 Changed 11 months ago by pruzand

  • Cc pruzand added

comment:5 Changed 11 months ago by pruzand

  • Cc seb added

comment:6 in reply to: ↑ 1 ; follow-up: Changed 11 months ago by axemclion

Replying to bill:

I was hoping for some more detail, since dojo/touch also "wraps different input methods into a single way to listen to events... supporting these multiple input methods using a single event listener". I assume the link you mean is http://www.w3.org/TR/pointerevents/, so AFAICT the difference between dojo/pointer and the current dojo/touch is:

  • different names for events (pointer.down instead of touch.start, etc.)

This is to enable a module that resembles the pointer events more closely.

  • expose properties like input type, tilt

In addition, it would also expose properties to let the user decide if the input was from mouse or from touch, if required.


Sounds like #16944 is not addressed by this ticket?

Yes, #16944 is not addressed by this issue.

This could either be a separate module - dojo/pointer, or change the dojo/touch. I thought a new module would help so that people using the touch module are not broken.

comment:7 in reply to: ↑ 6 Changed 11 months ago by bill

A new module is fine, but dojo/touch should be deprecated and (if possible) modified to delegate to dojo/pointer.

comment:8 Changed 10 months ago by cjolif

  • Milestone changed from tbd to 2.0
  • Owner set to seb
  • Status changed from new to assigned

comment:9 Changed 10 months ago by seb

I start to work on a prototype which implements PointerEvents specification. I will update this thread when I will have something to share on GitHub.

comment:10 Changed 10 months ago by seb

When using a touch screen, both touch and legacy mouse events are fired. In order to normalize this and fire only one Pointer Event, we need a way to correlate mouse and touch events related to the same user action (to "absorb" unwanted mouse events). I noticed such events have the same coordinates (tested on Android and MSIE10). We could leverage this but this behavior is not part of a specification.

For CSS touch-action, we need to handle browser with and w/o support of touch-action. We coud introduce a property element "dojo-touch-action" to emulate the css property "touch-action".

Also, we do not expect to dynamically add/remove touch-action capability on elements, and Mutation Observer are not available in current browsers, so I suggest not to handle dynamic add/remove of touch-action capability.

comment:11 follow-up: Changed 10 months ago by seb

Last edited 10 months ago by seb (previous) (diff)

comment:12 follow-up: Changed 10 months ago by sgrebnov

Hi guys,

Could you please review my implementation of Pointer events support? At the moment all the code related to the pointer events is located in my forked repos on Github:
Dojo: https://github.com/sgrebnov/dojo/commits/pointer-events
DojoX: https://github.com/sgrebnov/dojox/commits/pointer-events

Implemented:

  1. Pointer module (very similar to Dojo touch.js implementation pattern).
  2. Added two test pages to dojo repo (tests/test_pointer.html, tests/test_pointer_paint.html)
  3. Updated code to use Pointer instead of Touch module

I'm looking for the two action items from your side:

  1. Code review and feedback.
  2. I see that SVN Dojo version looks older than Github version so could you please clarify how I should contribute the code - via Github pull request or, as usual, via SVN patch.

Thank you,
Sergey

comment:13 in reply to: ↑ 11 ; follow-up: Changed 9 months ago by bill

Replying to seb:

On GitHub: https://github.com/seb-pereira/PointerEvents

That link doesn't work. Oh actually it's working now, but it doesn't have anything besides a README file??

Last edited 9 months ago by bill (previous) (diff)

comment:14 in reply to: ↑ 12 ; follow-up: Changed 9 months ago by bill

Replying to sgrebnov:

Hi guys,

Could you please review my implementation of Pointer events support? At the moment all the code related to the pointer events is located in my forked repos on Github:
Dojo: https://github.com/sgrebnov/dojo/commits/pointer-events
DojoX: https://github.com/sgrebnov/dojox/commits/pointer-events

I looked at the code in dojo. It's a lot to take in, and hard to read the diffs since you've split the changes across three separate commits, but I wrote some comments in github.

My main observations is about the general architecture, see https://github.com/sgrebnov/dojo/commit/a2e3ddf217b9023ce3f5f2ee74720f74ced1efbb#commitcomment-3599578.

Also, does the dojoclick code really belong there? It's not part of the Pointer spec. I thought there was something else in the Pointer spec about fast clicks, like a CSS property?

  1. I see that SVN Dojo version looks older than Github version so could you please clarify how I should contribute the code - via Github pull request or, as usual, via SVN patch.

Dojo was switched to git a few months, so use github, not SVN.

comment:15 in reply to: ↑ 13 ; follow-up: Changed 9 months ago by seb

That link doesn't work. Oh actually it's working now, but it doesn't have anything besides a README file??

Initial commit and documentation should now be available.

comment:16 in reply to: ↑ 15 ; follow-up: Changed 9 months ago by bill

Replying to seb:

That link doesn't work. Oh actually it's working now, but it doesn't have anything besides a README file??

Initial commit and documentation should now be available.

I don't know where to start to review that patch, because it's not a patch. It has just a single commit with thousands of files and none of them are named dojo/pointer.js. You should instead fork the standard dojo, dijit, and dojox repositories, and then have commits with your changes.

Last edited 9 months ago by bill (previous) (diff)

comment:17 in reply to: ↑ 16 Changed 9 months ago by seb

Replying to bill:

I don't know where to start to review that patch, because it's not a patch. It has just a single commit with thousands of files and none of them are named dojo/pointer.js. You should instead fork the standard dojo, dijit, and dojox repositories, and then have commits with your changes.

You are right, this is not a patch and it was not my intention to provide a patch. This implementation has no direct dependencies with dojo at this time. It only benefit from dojo AMD loader. Dojo projects are just copy/rebase from 1.x master with no changes. Once Pointer Events implementation done and tested, the integration step will begin.

The current objective is to provide a functional implementation that gives consistent results (same workflow of synthetized Pointer Events) on targeted environments (Android, BB, iOS, MSIE). For the integration step I will consider a fork of DUI.

That beeing said, you can find everything related to Pointer Events under the "pointer" folder:
https://github.com/seb-pereira/PointerEvents/tree/master/pointer

Current implementation is based on this analysis:
https://github.com/seb-pereira/PointerEvents/wiki/Mapping-between-touch-and-Pointer-Events

At this point the normalization of touch events into Pointer Events is almost complete. (normalization of mouse events/MS Pointer Events and implementation of Pointer Events capture feature are ongoing).

Last edited 9 months ago by seb (previous) (diff)

comment:18 follow-up: Changed 9 months ago by bill

OK, I can see the files in https://github.com/seb-pereira/PointerEvents/tree/master/pointer but I can't comment on them because your initial commit is so big. In other words, github won't let me (or anyone) get to the part of your single commit about those files.

comment:19 follow-up: Changed 9 months ago by bill

So I'd advise you to recreate the repository where dojo, dijit, and dojox are submodules. Or if you need to modify the files in those directories, then recreate the repository, first committing those existing files, and then checking in the pointer code as a separate commit.

Anyway, I have lots of little comments about the code, but the main one is that you seem to be missing all the target related code for touchmove. As the user moves his finger from one node to another, it should generate pointerover and pointerout events. In addition the app needs to be able to setup pointerenter and pointerleave events. And finally, while touchmove's target is always the node that was originally touched (i.e. the touchstart node), the pointermove target (IIUC) is the node that the mouse is currently over, and the relatedTarget is the node that the mouse was previously over.

Last edited 9 months ago by bill (previous) (diff)

comment:20 in reply to: ↑ 19 Changed 9 months ago by seb

Replying to bill:

As the user moves his finger from one node to another, it should generate pointerover and pointerout events.

Yes, it was not implemented but it is now available and the target reflects the "elementFromPoint" for touch events mapping. Mouse event mapping is also available now.

In addition the app needs to be able to setup pointerenter and pointerleave events.

enter and leave events are not implemented in IE10. In IE11 preview both events are available. I will add them when I finish to implement the pointer capture.

Once pointer capture is available I will follow your advice and make the necessary changes on GitHub.

Last edited 9 months ago by seb (previous) (diff)

comment:21 in reply to: ↑ 14 Changed 9 months ago by sgrebnov

Bill, thank you for reviewing the code. I've addressed your notes by two additional commits to pointer-events branch.

Replying to bill:

My main observations is about the general architecture, see https://github.com/sgrebnov/dojo/commit/a2e3ddf217b9023ce3f5f2ee74720f74ced1efbb#commitcomment-3599578.

If it does not block us from submitting/applying current implementation I would like to complete this and then review/plan this change and other improvements.

Also, does the dojoclick code really belong there? It's not part of the Pointer spec.

I've copied the dojoclick code from touch.js for backward compatibility. My main goal was to allow developers to easily switch from touch to pointer module. If we move this functionality to separate place developers will have to modify their code.

I thought there was something else in the Pointer spec about fast clicks, like a CSS property?

Valid implementation of pointer spec css properties is a complex task. I propose to complete core support first and then review if we really want to add additional logic.

comment:22 in reply to: ↑ 18 Changed 9 months ago by seb

Replying to bill:

OK, I can see the files in https://github.com/seb-pereira/PointerEvents/tree/master/pointer but I can't comment on them because your initial commit is so big. In other words, github won't let me (or anyone) get to the part of your single commit about those files.

https://github.com/seb-pereira/pointer

I finally put a new pointer project here https://github.com/seb-pereira/pointer.

  • There are no direct or indirect dependencies with Dojo at this point.
  • Samples and tests applications Pointer module are loaded using requireJS.

As I mention in the README this API implements a W3C Pointer Events like set of events and also some features out of scope of the specification. The idea behind is that it could not only expose Pointer events, but also provide other things currently provided by Dojo touch, such as synthetic click. Eventually it could act as a unified pointer API to replace Dojo touch.

comment:23 Changed 9 months ago by seb

Pointer Event specification defines values for Pointer events button and buttons (http://www.w3.org/TR/pointerevents/#chorded-button-interactions).

I have 2 issues here:

1) - It is not possible to set button=-1 because browsers implementation of button is unsigned int (no problem to assign -1 but subsequent access to the property gives 65535 or 0 depending on the browser type)
2) - For touch pointer type, the specification indicates buttons value should be 1. However, Internet Explorer 10 and 11 preview set buttons=0. In that case it is not possible to force the value of buttons because once the event is created the property is read only.

One possible solution would be to define custom properties on synthesized Pointer events (djButton/djButtons for example).

Any thought about this?

comment:24 follow-up: Changed 9 months ago by sgrebnov

Hi,

To finalize my work on Pointer module I need the following information. Could someone help me?

General architecture improvement
I see that this is very reasonable change so that we don't normalize same event object many times. But in this case we have to fire our custom events with support of stop/cancel propagation functionality and I have a concern about old browsers. What browsers are going to be supported by Pointer module?

dojoClick
Agree this functionality should be moved out from Pointer module. Please recommend the place where I should move it.

comment:25 in reply to: ↑ 24 ; follow-up: Changed 9 months ago by bill

Replying to sgrebnov:

What browsers are going to be supported by Pointer module?

For desktop I think IE9+ and the latest version of other browsers. I'm not sure exactly which mobile versions we'll support but I'm pretty sure all of them have addEventListener(name, callback, true). It's unclear what you mean by "stop/cancel propagation functionality".

dojoClick
Agree this functionality should be moved out from Pointer module. Please recommend the place where I should move it.

I don't know, perhaps a module called click?

comment:26 in reply to: ↑ 25 ; follow-up: Changed 9 months ago by sgrebnov

Replying to bill:

It's unclear what you mean by "stop/cancel propagation functionality".

I meant properly support of event propagation (capturing/bubbling)with ability to invoke .stopPropogation(). The el.dispatchEvent() and IE specific el.fireEvent() methods seem to do it right so we can just rely on them.
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget.dispatchEvent
http://msdn.microsoft.com/en-us/library/ie/ms536423%28v=vs.85%29.aspx

Another idea. If we just want to prevent same event to be converted several times we can just proceed with the following singleton pattern.

normalize event only if it has not been done before

if (!originalEvent.pointerEvent){

originalEvent.pointerEvent = makePointerEvent(originalEvent);

}

dispatch event

listener.call(self, originalEvent.pointerEvent);

Pros: super easy to implement, no need to always listen for all touch/mouse events on document level; follow existing Touch module implementation pattern. Cons: not so beautiful from architecture point. Bill, what do you think?

comment:27 in reply to: ↑ 26 ; follow-up: Changed 9 months ago by bill

Replying to sgrebnov:

Another idea. If we just want to prevent same event to be converted several times we can just proceed with the following singleton pattern.

normalize event only if it has not been done before

if (!originalEvent.pointerEvent){

originalEvent.pointerEvent = makePointerEvent(originalEvent);

}

dispatch event

listener.call(self, originalEvent.pointerEvent);

Well, I was worried that you are setting up 2x listeners on webkit and gecko. on(node, pointer.down, callback) requires internally setting up both touchstart and mousedown listeners. I don't know if that's a practical issue or not; users probably aren't (and shouldn't be) setting up lots of event handlers anyway, but generally we try to optimize page load time ("load" including initial page setup).

There's also just the thing about consistency, where IIRC you are setting up a touchmove listener on the document., so it makes sense to setup other listeners on the document too.

Anyway, we're in a silly situation now where Sebastien has gone off on his own implementation so now you two guys are competing with each other, so I don't know where we go from here.

comment:28 in reply to: ↑ 27 Changed 9 months ago by axemclion

Replying to bill:

Anyway, we're in a silly situation now where Sebastien has gone off on his own implementation so now you two guys are competing with each other, so I don't know where we go from here.

Is there a way we could combine our efforts ? Do you know how much progress has Sebastein made ? Given that Sergey's code is almost complete, can we derive one work from the other ?

comment:29 Changed 6 months ago by seb

Shim implementation of Pointer Events is now hosted in this repo: https://github.com/ibm-dojo/pointer

Note: See TracTickets for help on using tickets.