Better recognition of pointer events #2745

[si13b]

I've mainly focused on recognising the native event, rather than providing any abstraction. We can possibly look at bringing some of the PointerEvent properties into DOMEvent?

http://www.w3.org/TR/pointerevents/#pointerevent-interface

[SergioCrisostomo]

I think its a good idea to add pointer events.

Maybe we should add some abstraction when (!window.PointerEvent || (window.MSPointerEvent && !('onpointerdown' in window))). Listen for mouse and touch events setting the pointer events e.pointerType to resp. mouse or touch.

So we can do .addEvent('pointerdown', fn); in older browsers. Otherwise adding this functionality just in some browsers might be misleading.

[arian]

I don't think we should do the .addEvent('pointerdown', fn) polyfill for older browsers or browsers that don't support it yet, see https://github.com/jquery/PEP

What could be added is something like https://github.com/mootools/mootools-core/blob/master/Source/Types/DOMEvent.js#L73-L84 for pointer events, so all the interesting properties are available on the MooTools DOMEvent object too.

[SergioCrisostomo]

@arian good point. In that case there should be a short info about that in Docs that this is only supported for modern browsers.

[arian]

Yes. Same for touchevents, those are not documented at all yet http://mootools.net/core/docs/1.5.2/Types/DOMEvent

[SergioCrisostomo]

@si13b do you have possibility to add that ^ ? that would be really nice.

[si13b]

Yes, should be able to.

[SergioCrisostomo]

@si13b nice addition!

@arian can it be something like:

 [Touch](http://www.w3.org/TR/touch-events/#list-of-touchevent-types) and [Pointer Events](http://www.w3.org/TR/pointerevents/#pointerevent-interface) are only available in modern browsers that support it.

being added to docs, (maybe here)?

[si13b]

@SergioCrisostomo thanks! Do you want me to add another commit to update the docs, or should we do that in a separate PR?

[SergioCrisostomo]

@si13b yes, please add documentation so ir goes together with the code.

Thank you

[SergioCrisostomo]

:+1: lgtm

[si13b]

Cool :+1:, can we merge? :-)

[timwienk]

What are the reasons we don't want to polyfill pointer events for older browsers, at least its basic behaviour (I realise things like width, pressure and tilt are probably not doable, but I'd guess pointer events in general could work when fired through mouse and touch events)?

One of MooTools Core's main goals has been to abstract differences between browsers. I realise MooTools development is mostly maintenance and keeping it working with recent standards now, but if the features we add can be supported in all browsers we support, I think they should be (we would have in the past, in such a case).

Other than that, the work that is done looks good (so definitely :+1: and :smiley: for that). But to merge into master (and thus be releasable), I'd like to either be convinced we indeed shouldn't polyfill basic pointers for older supported browsers, or otherwise see an effort towards basic support.

Another request, could you rebase your branch on top of the latest mootools/master? We've added a few things to the automated tests since your fork.

[si13b]

@arian suggested we not polyfill and my understanding of the reasons was basically that there are already other quality options out there (i.e. https://github.com/jquery/PEP). Also, it gives users the choice if they want to polyfill or not.

I am not personally adverse to polyfill, and it does seem to be inline with the project goals.

I raised this issue primarily to simply recognize pointer events (at present, you cannot even el.addEvent('pointerdown', handler);), so you could look at it as the first step towards more advanced support.

Sure thing, I'll do the rebase. Should I also squash the commits down, or not fussed?

[timwienk]

I'm not fussed about squashing, in most cases I actually don't like it, since you destroy history that might actually useful to be able to understand why/how a decision (or error) was made. I personally do amend stupid/syntax things onto the commit they fix up, but again, not really fussed. I believe the reason people like to squash is to have a shorter/cleaner history, for which one could just as well use git log --merges (in fact, if every change set is squashed after rebasing, why have merge commits at all).

[si13b]

I've completed the rebase, did we make a decision about polyfilling or not?

[SergioCrisostomo]

I think you can remove the old IE tests (IE8, 9 and 10). Otherwise I'm ok to merge this. Again, nice work!