SGTM

It would be great if we had a way to make every property of the original event available on the jQuery one with O(1) overhead with regards to the number of properties but that's not possible without ES2015 Proxies, unfortunately. :(

Proxy itself if pretty slow, but of course defineProperty is slow too. Ideally we'd be able to have jQuery.Event use native Event as its prototype but that doesn't work on all browsers, I tried it. For all its drawbacks this approach is faster and smaller than our old code, so I guess that's progress!

Ideally we'd be able to have jQuery.Event use native Event as its prototype but that doesn't work on all browsers, I tried it.

Could you share which browsers are problematic here?

Strange day, I can't type into either jsbin or jsfiddle. Here's a codepen: http://codepen.io/anon/pen/aNPgyg?editors=0010

Chrome gives "illegal invocation", Edge gives "invalid calling object", Firefox gives "TypeError: 'get type' called on an object that does not implement interface Event." I thought for sure that one of those three actually worked last time I tried it. The Event object is really a host object so I guess that's to be expected.

I saw the PR before, but just now noticed this issue. We should add pointerId as well based on the title of this issue. It's probably safe to leave the other new properties out for now.

I'm conflicted about how far to go with this. We were trying to avoid setting an hook API in concrete for 3.0.0 so we could find out what is out there. This was just to prevent immediate pain from people using those plugins. Most people using Pointer Events will be using PEP so adding those pointerId won't help them. Or will it? Can you take advantage of this in PEP and if so what would you like to see?

For jQuery4 we need to figure out how to get out of the event object hacking business.

Sorry for the long delay, this got buried in my inbox :-/

Most people using Pointer Events will be using PEP so adding those pointerId won't help them. Or will it? Can you take advantage of this in PEP and if so what would you like to see?

It will definitely help people using PEP. We wouldn't take advantage of this inside PEP, but it will allow users to use event.pointerId directly, as long as they've loaded PEP on the page. We have a small section in the PEP README about using PEP with jQuery. We show a simple example that only cares about coordinates so there's no special work. However, the two most common pointer-specific properties that people will check are pointerId and pointerType. I'd love to see both of these included, but pointerId seems like the minimum requirement to me since it will allow users to determine if the events are from the same pointer.

We do defer listing which properties will work on event and which require using event.originalEvent to jQuery's API docs specifically because this is version dependent and changes over time. So the direct impact on PEP is zero (no code changes, no docs changes), but the indirect impact through developer ergonomics is real. If we want to push Pointer Events as much as we can, we should reduce friction as much as possible.

I'd love to see pointerId included in core, and then we can just create a plugin that adds the other properties so users can weigh the pros and cons on their own and decide if they want the benefit of accessing the properties directly. I expect this will become more of an issue when the implementations are no longer behind a flag and every browser except Safari will have these properties exposed automatically. Then users will add PEP to get support in Safari, but certain properties just won't exist. At that point, we may want to just include the properties plugin directly in PEP.