Skip to content
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

Should on(got/lost)pointercapture be in GlobalEventHandlers? #157

Closed
NavidZ opened this issue Dec 6, 2016 · 21 comments

Comments

Projects
None yet
6 participants
@NavidZ
Copy link
Member

commented Dec 6, 2016

Similar to other onpointer"event" handlers, should we also have on(got/lost)pointercapture handlers added to GlobalEventHandlers instead of Element interface?

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2016

@teddink @jacobrossi
I was wondering if there was a particular reason that Edge puts on(got/lost)pointercapture for Element instead GlobalEventHandlers along with others on"event" handlers and whether you think it is okay to put on(got/lost)pointercapture beside the others for consistency.

@RByers

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2016

setPointerCapture is on Element so doesn't that mean only an Element can ever receive gotpointercapture / lostpointercapture events? I think all implicit capture scenarios should be to Element also, right? In particular, GlobalEventHandlers also applies to Document and Window.

@dtapuska

This comment has been minimized.

Copy link

commented Dec 7, 2016

the events bubble

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2016

Sure. I agree that those capturing API should remain in an Element. But on(got/lost)pointercaptures bubble up so they can be handled with something on the window presumably.

@RByers

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2016

Duh, good point :-). I can imagine event delegation frameworks really wanting to listen on window. I assume you see the events bubble up to window on Edge when using addEventListener, right? Assuming that's the case, then I agree the ongotpointercapture etc. properties should be consistent and live in GlobalEventHandlers also.

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2016

Yes. Both on Edge and Chrome, when you add a gotpointercapture listener via addEventListener to the window it does get triggered when an element inside gets the capture and yet neither of browsers have ongotpointercapture defined on window.

@NavidZ NavidZ added the test label Dec 7, 2016

@teddink

This comment has been minimized.

Copy link

commented Dec 7, 2016

I am following up with dev and spelunking through the code a bit to see if there is a reason.

@NavidZ NavidZ self-assigned this Dec 14, 2016

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 14, 2016

@teddink were you able to get any updates on this one?

@teddink

This comment has been minimized.

Copy link

commented Dec 14, 2016

Yes I was - there is no specific reason why, we intend to make the same change.

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 14, 2016

So does this PR sums up all the changes needed?

@teddink

This comment has been minimized.

Copy link

commented Dec 14, 2016

The PR looks good to me. We should add a test as well :-)

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 14, 2016

Yup. I have the test ready as well actually. I'm going to send it as soon as the spec PR lands.

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 19, 2016

The test landed as well and this issue can be closed now.

@NavidZ NavidZ closed this Dec 19, 2016

@bzbarsky

This comment has been minimized.

Copy link

commented Dec 19, 2016

the events bubble

@dtapuska Not per the spec as currently written, right?

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 19, 2016

In the Pointer Event types section it is specified that the got/lostpointercapture events bubble. Also both the Edge and Chrome implementations do that.

@bzbarsky

This comment has been minimized.

Copy link

commented Dec 19, 2016

@NavidZ The actual processing model fires a non-bubbling event. Specifically, https://w3c.github.io/pointerevents/#the-gotpointercapture-event says to https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface which will call into https://dom.spec.whatwg.org/#concept-event-fire which by default fires a non-bubbling event. There is no mention of setting "bubbles" to true in https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface.

The table you link to has no obvious normative status that I can see, in the sense that it's not clear how to actually apply the data in that table to anything.

If the spec is wrong and the event should actually be bubbling, please fix the spec.

@bzbarsky

This comment has been minimized.

Copy link

commented Dec 19, 2016

Ah, I see. There's the "whose attributes are set as defined in PointerEvent Interface, and Pointer Event types." bit @RByers pointed out.

I think saying "whose 'bubbles' and 'cancelable' attributes are initialized as defined in ..." would help clarity a lot here.

@bzbarsky

This comment has been minimized.

Copy link

commented Dec 19, 2016

And specifically, from the current wording it's not clear that the "Sync/Async" column does not correspond to an IDL attribute, but the Bubbles and Cancelable columns do.

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 19, 2016

This is not only about that table. That section has a whole bunch of attribute initialization for different events. The firing section used to list them all but as they got bigger in one of the pull requests we changed it to just point to that section. Regarding Sync/Async I agree with you. But what do you suggest?

@bzbarsky

This comment has been minimized.

Copy link

commented Dec 19, 2016

I think it would make sense to explicitly say that bubbles/cancelable are set per the table and the other IDL attributes are set per the prose in https://w3c.github.io/pointerevents/#pointer-event-types though the indirectness of needing to know which event caused the algorithm to run (but that event not being an argument to the algorithm) is pretty unfortunate. Being more explicit there would have been better too.

@NavidZ

This comment has been minimized.

Copy link
Member Author

commented Dec 20, 2016

@bzbarsky do you mind filing another issue for that so we can track it separately?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.