-
Notifications
You must be signed in to change notification settings - Fork 33
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 a captured pointer send boundary events by default? #61
Comments
Hit testing and calling An extra arg to |
Thanks Dave!
Yes. However it's possible that manual use of
Agreed, that would be ugly and confusing (would only exacerbate the "transition events have 2 fundamentally different semantics" concern). |
This actually just came up with a PEP user (unrelated to the transition events during capture though): jquery-archive/PEP#280 I think there will be a lot of work to educate developers about properly throttling DOM manipulation. The tools are available, but the community as a whole still has a long way to go. But this is a much broader issue than what's being discussed here. |
We discussed this on the call today and nobody present could explain why the button scenario would want capture at all, it's most easily implemented by not using capture and having only a I argued there are 3 consistency principles we're trying to uphold here:
Chrome is going to proceed with implementing this model for now (since it's much simpler and we don't have a good understanding of why the more complex Edge behavior is useful) and get some data on web compat. In parallel @teddink is going to talk with @jacobrossi and see if they can explain the benefits of Edge's current behavior. |
@scottgonzalez / @smaug---- suggest using the term "boundary events" to avoid confusion with transition events. |
Here is a short video of the Windows 10 built in "modern" Mail app: Mail App Video Another example, although contrived and clearly not something that a designer would ever sign off on, can be seen here: http://teddin.azurewebsites.net/test/pointereventbutton.html Does this better explain the button scenario referenced above? |
that is essentially what I was talking about in the last call (when mentioning also how this provides the ability for users to change their mind after they started to put their finger on the button, but then don't want to execute). i think it was scott who then said that you wouldn't really do this with pointer events and capture, but just listen for click (for the action itself, which will only trigger when the end point when the finger was lifted is in the same element as where it started). probably throw in a |
Although that particular UI seems weird to me but I guess that's just me and I totally agree we should make it possible for a developer to implement that UI. |
As far as I can tell, Edge doesn't implement that behavior for native |
@scottgonzalez - Correct, Edge does not implement an implicit capture on the Regarding the hit testing aspects of the discussion - I do not have any tests or data, but I do wonder if the UA can make more optimizations in its hit testing than the web developer can in JavaScript. To put it another way, I am questioning whether a hit testing loop in JavaScript is really equivalent to a hit testing loop inside the UA. I do agree that the same behavior that I was able to produce in my sample could be accomplished with hit testing in JavaScript and does not specifically require the enter and leave events. The code does seem simpler to me with the enter and leave events - but that may just be me. |
To summarize, I think we're all on the same page wrt. the use case, the debate is just centering around how easy/hard the different ways to implement that use case are:
Does someone want to try writing the simplest possible code they can for these 3 scenarios so we can compare them concretely? Of course ease of development is just one issue here, once we have some conclusion from that we also need to consider (arguably more important):
That's not the case in blink at least. |
But you could optimize out most of the hit testing if you detected the relevant area in compositor side. |
Implementations of various approaches to the button capture use case:
|
Maybe using clientX/Y is better for that? I don't know if there is a case that this one missing |
That works. I've updated the links in my previous comment. Thanks. |
Thanks Scott. For the captured w/ boundary events case we also need a bit of custom logic to handle clicks, right? I guess it's just a click handler that bails out if the active class isn't applied? It's having to ignore some click events that makes using capturing feel a little hacky to me (the button doesn't really want all events, it just doesn't want anyone else to get them). |
If you press down on button A, move to button B, and release, you shouldn't get a click on either of the buttons. |
Oh, right - IMHO that violates the spec for |
Assuming you're in a sane scenario where the pointer is captured to an element that received |
Similar to my comment on #75, if an element gets both |
I have some initial data that we can analyze more deeply. Here is what I did - I grabbed the top 200 sites form our usetracker data that use pointer events. I then did static analysis from crawler data to find sites that had the text Pointer events in use AND Pointer events in use AND Pointer events in use AND NEXT STEPS:
|
Oops - did not mean to close the issue - reopening. |
Initial attempt to address #61 (in the reduce-hit-tests branch only for now).
In the meeting at TPAC we agreed that for now we're OK with not sending boundary events by default - as written in the reduce-hit-tests branch. We've got an open question about what is the best behavior for explicit capture (and whether the capture API should change) - filed #143 for that. |
Edge and the spec send
pointerleave
/pointerout
when a captured pointer moves outside the bounds of an element (and it's descendants), andpointerenter
/pointerover
whenever it moves back in.There's been some discussion in various places about the implications of this and whether it should change, so I offered to file a dedicated issue to summarize the arguments to see if we can come up with a plan here. In particular, this is a subset of Chrome's primary ship-blocking spec issue: #8.
I'll try to keep the above summary updated as we debate the details in the conversation below.
Advantages of sending transition events during capture
click
events seen afterpointerleave
, so it's mostly acting like an uncaptured control, right?Disadvantages of sending transition events during capture
pointermove
events during capture (Pointermove should not require a hit-test by default for touch #8)pointermove
events after it sees apointerleave
. As currently defined, when an element has capture the transition events no longer say anything about the event stream.pointerover
andpointerout
events normally apply only to the immediate bounds of the element, but under capture they (currently) behave likepointerenter
andpointerleave
where they reflect the bounds of the captured element and all it's descendants. We're struggling to define this precisely (Clarified definition of capturing element borders #63, Determine when boundary events are fired after capture is released #15)pointerleave
andpointerenter
events as the dragged element is continually repositioned to remain underneath the mouse cursor.Possible alternatives
:hover
and transition events).elementFromPoint
) or boundary checks onpointermove
listeners. This should be simple to do.pointerlevae
handler is invoked during capture doesn't mean that the handler's behavior was actually desired by the developer). Thoughts?setPointerCapture
to specify the behaviorWhat have I missed / got wrong in this summary? Other arguments / details? /cc @scottgonzalez @jacobrossi,
The text was updated successfully, but these errors were encountered: