Bug Tracker

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#14741 closed feature (fixed)

Improve compatibility with Pointer Events

Reported by: Louis-Rémi Owned by: lrbabe
Priority: low Milestone: 1.11.1/2.1.1
Component: event Version: 2.1.0
Keywords: Cc:
Blocked by: Blocking:

Description (last modified by lrbabe)

"Pointer Events unifies the web event model for touch, mouse, and pen input. It is designed to address concerns with the Touch Events spec."

This microsoft-proposed spec is already implemented in IE10 and IE11, patches are about to land in Firefox and work is underway in Chromium. More importantly, Microsoft is providing a polyfill that allows to use those events today in all major browsers.

jQuery lacks only minor modifications to be compatible with these events and their polyfill:

  • pageX, pageY and other mouseevent-related properties aren't passed on to the handler
  • event delegation doesn't work with pointerenter and pointerleave

To clarify: this ticket isn't about making those events available in all browsers jQuery supports. The aim is simply to improve the compatibility of jQuery with the browsers that implemet them and with the Hand.js polyfill.

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

Compared to last run:

  • dist/jquery.js: raw +67 / gz +25
  • dist/jquery.min.js: raw +61 / gz +21

Change History (16)

comment:1 Changed 9 years ago by scottgonzalez

Resolution: plugin
Status: newclosed

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.

comment:2 Changed 9 years ago by lrbabe

Component: unfiledevent
Description: modified (diff)
Resolution: plugin
Status: closedreopened

comment:3 Changed 9 years ago by lrbabe

I've reopened the ticket with permission from DMethvin, see clarification in the ticket. PR: https://github.com/jquery/jquery/pull/1503

Last edited 9 years ago by lrbabe (previous) (diff)

comment:4 Changed 9 years ago by lrbabe

Description: modified (diff)

comment:5 Changed 9 years ago by lrbabe

Summary: Handle Pointer EventsImprove compatibility with Pointer Events

comment:6 Changed 9 years ago by Timmy Willison

Owner: set to lrbabe
Status: reopenedassigned

comment:7 Changed 9 years ago by dmethvin

Milestone: None1.11.1/2.1.1
Priority: undecidedlow

comment:8 Changed 9 years ago by louisremi

Event: Treat Pointer events like mouse events, #14741

Ref #14741 Ref gh-1503

Changeset: e06f428f6ed99e0fafb2e21c456eafc570e3e5ba

comment:9 Changed 9 years ago by Dave Methvin

Resolution: fixed
Status: assignedclosed

Event: Unit test for #14741 fix

Fixes #14741 Closes gh-1503

Changeset: 472f70a9df75c289393d6618c36257a04f9cb902

comment:10 Changed 9 years ago by 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.

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.

comment:11 Changed 9 years ago by scottgonzalez

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.

comment:12 in reply to:  10 Changed 9 years ago by lrbabe

Replying to 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.

comment:13 Changed 9 years ago by 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.

comment:14 in reply to:  13 ; Changed 9 years ago by r.otten@…

Replying to 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 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?

comment:15 Changed 9 years ago by dmethvin

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.

comment:16 in reply to:  14 Changed 9 years ago by scottgonzalez

Replying to 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.

Note: See TracTickets for help on using tickets.