Please don't send a PR to add this to core. If you'd like to help with this, you can send PRs to https://github.com/jquery/jquery-pointer-events which builds on top of Polymer.

We need to iterate outside of core's release cycle.

I've reopened the ticket with permission from DMethvin, see clarification in the ticket.

PR: https://github.com/jquery/jquery/pull/1503

Event: Treat Pointer events like mouse events, #14741

Ref #14741

Ref gh-1503

Changeset: e06f428f6ed99e0fafb2e21c456eafc570e3e5ba

Event: Unit test for #14741 fix

Fixes #14741

Closes gh-1503

Changeset: 472f70a9df75c289393d6618c36257a04f9cb902

Current fix is insufficient to really use pointer events as they are meant. Essential properties such as pointerType and pointerId are still not forwarded. Chorded button presses are not present. Pressure is not present. etc.

Also, you do not take into account and normalize the MS-prefixed event names available in IE10. The events themselves also require further normalization on several properties, because IE10 was built against an older version of the spec proposal. E.g. in IE10 the pointerType is still an integral number instead of a string constant.

If you're going to integrate support & normalization for pointer events, either tackle it completely or don't tackle it at all and leave support to a plugin.

Infact; given the fact that a polyfill is going to be desirable to support both legacy browsers and browsers from parties that are holding off on implementing pointer events (i.e. Apple Safari), maybe you should leave support out of core altogether and make pointer-event support its own thing completely.

Also, I feel that building such a polyfill plugin as a simple adapter around and on top of Polymer is a bad idea. While re-using existing working solutions is in general a good idea, Polymer adds far too much weight for old browser support to be viable in the general case.

Infact; given the fact that a polyfill is going to be desirable to support both legacy browsers and browsers from parties that are holding off on implementing pointer events (i.e. Apple Safari), maybe you should leave support out of core altogether and make pointer-event support its own thing completely.

That's what we're doing in https://github.com/jquery/jquery-pointer-events

Also, I feel that building such a polyfill plugin as a simple adapter around and on top of Polymer is a bad idea. While re-using existing working solutions is in general a good idea, Polymer adds far too much weight for old browser support to be viable in the general case.

6k min+gzip is too much? I'm not sure how small you think we can make this given how complex pointer event normalization is.

Replying to [comment:10 r.otten@…]:

Current fix is insufficient to really use pointer events as they are meant. Essential properties such as pointerType and pointerId are still not forwarded. Chorded button presses are not present. Pressure is not present. etc.

Those properties are available on the event.originalEvent properties and can easily be copied to the normalized event object with the following snippet:

'down move up cancel enter leave out over'.split(' ').forEach(function( suffix ) {
	$.event.fixHooks['pointer' + suffix] = {
		props: $.event.mouseHooks.props.concat('pointerType', 'pointerId', ...),
		filter: $.event.mouseHooks.filter
	};
});

Also, you do not take into account and normalize the MS-prefixed event names available in IE10. The events themselves also require further normalization on several properties, because IE10 was built against an older version of the spec proposal. E.g. in IE10 the pointerType is still an integral number instead of a string constant. If you're going to integrate support & normalization for pointer events, either tackle it completely or don't tackle it at all and leave support to a plugin. Infact; given the fact that a polyfill is going to be desirable to support both legacy browsers and browsers from parties that are holding off on implementing pointer events (i.e. Apple Safari), maybe you should leave support out of core altogether and make pointer-event support its own thing completely. Also, I feel that building such a polyfill plugin as a simple adapter around and on top of Polymer is a bad idea. While re-using existing working solutions is in general a good idea, Polymer adds far too much weight for old browser support to be viable in the general case.

The point of this modification is not to normalize pointer events and I disagree with you regarding an "all or nothing" approach. There are browsers that already support standardized pointer events, and there are developers who already use Polymer or Hand.js in their projects. jQuery can be adapted to support those environments and use-cases with 21B, so let's do it.

The main attraction of this patch was the ability to use pointerenter/leave with event delegation in jQuery. That will be needed even with Polymer or on a browser that fully supports pointer events, since pointerenter does not bubble.

jQuery has never copied and/or normalized every property on event objects, only a small critical set. The rest should come from originalEvent. I don't see a problem with doing the mouse-ish properties of a pointer event since the code is there and it was trivial to activate for this case.

Replying to [comment:11 scott.gonzalez]:

6k min+gzip is too much? I'm not sure how small you think we can make this given how complex pointer event normalization is.

I was referring more to the weight of Polymer's own polyfills etc. to work with older browsers, unless in this case their pointer event polyfill is separate enough to live on its own.

However on the subject of filesize, 6k does still seems a bit much to me. I've been working on and off on implementing a pointer event polyfill based around jQuery and its system of special events myself as well. Padded down it is currently sitting at around 2k min+gzipped and is already fairly complete:

https://github.com/NetMatch/jquery-event-pointer

Replying to [comment:13 dmethvin]:

The main attraction of this patch was the ability to use pointerenter/leave with event delegation in jQuery. That will be needed even with Polymer or on a browser that fully supports pointer events, since pointerenter does not bubble. jQuery has never copied and/or normalized every property on event objects, only a small critical set. The rest should come from originalEvent. I don't see a problem with doing the mouse-ish properties of a pointer event since the code is there and it was trivial to activate for this case.

Duly noted.

One potential downside to this though: pointer event polyfills based on jQuery's special events will have to be very careful in overriding the correct bits and pieces that jQuery already sets up internally to forward mouse-like properties and to make pointerenter/-leave work with delegation. Any ideas on how 'safe' that would be and, with regards to future compatibility, would remain?

Polyfills should be happening below us, not above us. On future compat, my crystal ball is not good enough to tell what may happen but it seems like the rules wouldn't change since they are basically the same rules as for mouseenter.

Replying to [comment:14 r.otten@…]:

I was referring more to the weight of Polymer's own polyfills etc. to work with older browsers

I'm not sure what polyfills you're referring to; Polymer doesn't work with older browsers. We hook into it and make it work in older browsers ourselves.

unless in this case their pointer event polyfill is separate enough to live on its own.

PointerEvents is its own repository, like pretty much everything in Polymer. Perhaps you haven't actually looked at how Polymer is built and are just making assumptions based on the full scope of the project?

However on the subject of filesize, 6k does still seems a bit much to me. I've been working on and off on implementing a pointer event polyfill based around jQuery and its system of special events myself as well. Padded down it is currently sitting at around 2k min+gzipped and is already fairly complete: https://github.com/NetMatch/jquery-event-pointer

I see that's not handling touch-action and doesn't have any tests. We can also trim Polymer down since there are portions we will never use, like the dispatching and firing code. The 6k is just the size of Polymer PointerEvents as is. We're well aware of the trade-offs, this wasn't a decision made on a whim.