-
Notifications
You must be signed in to change notification settings - Fork 55
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
Pointerevent extension #346
Comments
Any updates? |
@slightlyoff any updates on our side or the TAG folks? |
Hi @alice, can we get an expedited review on this? We are waiting for the review to ship the predicted events api in chrome. |
How does this feature interact with shadow trees? What is the exact modification of the event dispatch algorithm required and where is the monkey patch specified? The description of the two methods lacks the detail to lead to interoperable implementations around these questions, as far as I can tell. |
@annevk can you explain a little more. |
@NavidZ say the target node is inside a shadow tree. How is the target attribute of the events returned by these two new methods updated to ensure the shadow tree does not leak? |
@annevk this spec does not specify when to set those targets. It just guarantees that they are the same as the event's target. It is up to UAs when to set them. For example in Chrome we have this lazy approach that we only set this when it is accessed. But regardless of that, the guarantee that the target of the events returned by these methods are the same as the target of the dispatched event should prevent that leak. WDYT? |
You need to define the actual architecture that makes that work. E.g., define that these events hold a pointer to some parent and redefine the target attribute's getter so it can sometimes return the some parent's target instead. That will make it possible to verify that it's safe and will ensure that other extensions don't clash with it. The actual implementation can still be different from that, as long as it's black-box indistinguishable. |
@annevk I haven't seen something like that around. |
I'm not sure what you mean. I'd expect this to require changes to the DOM Standard as well (e.g., you're proposing changes to It also seems this would potentially affect A similar thing is how |
The coalesced events or predicted events aren't really dispatched events. We wanted to avoid defining a new structure to avoid extra complexity. So we used the same event structure for simplicity and defined a bunch of attributes in this spec to be no-op (such as stopPropagation) or return default value. But at the same time I don't want to just add all sort of hooks which makes the specification all more complex. |
If these are only meant to carry some data using a dictionary would be a lot better, and likely easier, yes. |
Yeah. Everything is just a value except offsetX/Y attributes which are calculated with respect to the target. So technically when the target of the dispatched event changes (like in shadow DOM cases) the offset of these coalesced/predicted points also needs to be recalculated with respect to the new target. |
In that case it sounds like you still need some kind of more complicated setup. (But not that complicated. Objects have a pointer to the event and some of their getters do some calculations based on the |
I thought the idea was that one could handle coalesced events just like normal events, if needed, even if prototype was modified or so. |
Apologies for taking so long to get to this! We are in the process of trying to refine our processes to get quicker at working through our backlog, plus I missed the request to expedite. Unfortunately I found this somewhat difficult to review. An explainer would help greatly - the spec has only minimal explanation of the problem these new APIs are intending to solve, which means I'm having to somewhat guess at the context, which also makes the review more time consuming for me. In particular, I couldn't figure out from the spec what the purpose of |
@alice I have updated the introduction to explain the later addition of predicted events and pointerrawupdate to the introduction as well. I also cleared up the getCoalescedEvents explanation as well. Sorry that the introduction was missed as that section is probably going to be removed/rewritten once merged to the pointerevents specification. |
the demo link is a 404; perhaps this is the right location? |
Yeah, sorry that I update the demo link recently.... |
Thank you @lknik - we're hoping to merge the extension into what will become PE3 shortly, and will make sure to consider the implications for privacy/security of new features. |
Sure. Any information about the plan for PE3 would be welcome, too. I still need to look at it all. |
We believe we addressed major concerns from TAG in the latest version. There is also a brief explainer for the features in the repository. Feel free to file more issues against the PointerEvent repo if you want clarification on more stuff. |
Thanks a lot! The explainer does make the intent and constraints a lot more clear. We'll hopefully discuss this in today's call. |
We discussed this in our telecon today and we're happy with the use case and the broad design here. Happy to close this, but just some parting thoughts:
Thank you for your patience through this review process, and for your hard work on this API. |
Thanks @alice. Regarding the ReSpec issues and everything editorial we are going to fix them all. As a matter of fact this extension document is going to go away and we are going to merge the content one at a time to the main spec and keep everything fixed with no warnings/errors. Regarding the naming of it, just to give a little background Pointer Events working group actually had all different names including the one you suggested if I recall correctly. We intentionally said we need choose a hard word so people don't just randomly use it as it is a very niche API and hopefully that makes them go and look it up to see what it does and what "coalescing" means really. We knew most of the web apps should not care about or use these points for their use cases and using them would just hurt their performance and we were hoping this hard and more accurate word would serve that purpose as well. |
こんにちはTAG!
I'm requesting a TAG review of:
Further details (optional):
You should also know that...
[please tell us anything you think is relevant to this review]
We'd prefer the TAG provide feedback as (please select one):
The text was updated successfully, but these errors were encountered: