Closed jkieboom closed 7 years ago
My opinion generally is that dojo/touch
comes from a time when it was necessary to try to fill in the gaps that browsers had when dealing with touch events and unify them and provide synthetic ones in some cases.
dojo-widgets
should generally abstract users from specific DOM events, though all the specifics of all the UI interactions and widgets hasn't been defined.
Outside of widgets, are you seeing a use case where the targeted browsers for Dojo 2 (e.g. IE 10/11, Firefox, Chome/Opera, Safari 9+, Android 4.4+ and iOS 9+)? If there is a requirement, I would say we would be more likely to consider some sort of shim for Pointer Events since that seems to be the direction the standards are going (with Firefox, Chrome and Opera starting to enable them behind a feature flag.
Our original plan (see page 27 of the dojo/dom proposal was to leverage the Pointer Events Polyfill (PEP), so I think that would be consistent with the approach @kitsonk suggested, though it would be a bit inconsistent with our current approach of shims rather than polyfills (I've not thought through if there's a way to effectively shim instead of polyfill for pointer events).
There wouldn't be, which is potentially warrant a level of consideration.
Because dojo/widgets uses a virtual DOM though, as we have discussed before, dojo/dom does not play the same role as it was once envisioned, which is why I wanted to understand the use case so it can be introduced in a coherent way.
Agreed, my point was more around the idea of using the solid PEP, rather than anything specific about dojo/dom in this case.
I've only briefly looked at PEP before, but indeed the fact that it is a Polyfill is of some concern for us. We generally try to avoid including anything that can have transparent side-effects for the user. For example, with PEP it looks not to be possible to only have it active on the part of the document that we are responsible for (instead, every element that has touch-action="none"
is PEP-enabled). A shim for Pointer Events on the other hand sounds nice.
So the main use case, if I were to restate, is have some sort of API that for direct DOM events allows the end developer to unify different types HID events and deal with them as a "group", plus some structure specifically geared to make that easier for touch + pen + mouse?
Not sure that I completely follow that. Our immediate needs/requirements are quite simple, minimally, we are looking for cross-browser touch events. On top of that, if general pointer inputs would be unified as well (touch, mouse, pen), that would be even better (I think this is what you describe). That said, the unification of different input types is less important for us, since we will still want to specialize handling depending on the type of input (touch interaction is just fundamentally different from mouse interaction in many cases, we are not looking to unify the interaction behavior).
PointerEvents for us is nice because the terminology and events are all the same, so it just makes it easier to talk to.
Ok...
Then I think the challenge is how we can provide something like PointerEvents for those that explicit use the API versus some sort of global polyfill. I guess we should focus just on PointerEvents for now and if that provides a good pattern for compositing/filling/etc other events then great.
This has been added in https://github.com/dojo/widget-core/pull/389 . @rishson is there more to do here (e.g. touch for things besides widgets?), or should this be closed?
The original issue was about having something like PEP but coming from dojo, however in the mean time we had to go with (a slightly modified to make it a shim) PEP in any case. Therefore at least for us it's no longer necessary for dojo to provide outside-of-widgets touch support.
Closing this now as Dojo 2 bundles PEP.
I was wondering if there were any plans to have something equivalent to dojo/touch be part of dojo2.