New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure we support the common touch and pointer event properies #3104

Closed
dmethvin opened this Issue May 5, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@dmethvin
Member

dmethvin commented May 5, 2016

The two plugins I found that mess with event properties and might be popular are these:

https://github.com/aarongloege/jquery.touchHooks
https://github.com/timmywil/jquery.event.pointertouch

Rather than waiting for people to report a problem, let's be sure we added the relevant properties here. In particular, changedTouches and touches. By the time we remove pageX/Y we will still be way ahead on size.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol May 5, 2016

Member

SGTM

Member

mgol commented May 5, 2016

SGTM

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol May 5, 2016

Member

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. :(

Member

mgol commented May 5, 2016

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. :(

dmethvin added a commit to dmethvin/jquery that referenced this issue May 5, 2016

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin May 6, 2016

Member

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!

Member

dmethvin commented May 6, 2016

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!

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol May 6, 2016

Member

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?

Member

mgol commented May 6, 2016

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?

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin May 6, 2016

Member

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.

Member

dmethvin commented May 6, 2016

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.

@dmethvin dmethvin added the Event label May 6, 2016

@dmethvin dmethvin added this to the 3.0.0 milestone May 6, 2016

@dmethvin dmethvin self-assigned this May 6, 2016

@dmethvin dmethvin closed this in f595808 May 9, 2016

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez May 9, 2016

Member

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.

Member

scottgonzalez commented May 9, 2016

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.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin May 11, 2016

Member

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.

Member

dmethvin commented May 11, 2016

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.

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez May 31, 2016

Member

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.

Member

scottgonzalez commented May 31, 2016

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.

scottgonzalez added a commit to scottgonzalez/jquery that referenced this issue Jun 8, 2016

timmywil added a commit to timmywil/jquery that referenced this issue Jun 9, 2016

@lock lock bot locked as resolved and limited conversation to collaborators Jun 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.