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

Additional definitions exports for Pointer Events #6758

Open
plehegar opened this issue Jun 10, 2021 · 3 comments
Open

Additional definitions exports for Pointer Events #6758

plehegar opened this issue Jun 10, 2021 · 3 comments
Labels
anchor permanence Identifies issues opened by other standards organizations, as per WHATWG's anchor permanence policy editorial Changes that do not affect how the standard is understood

Comments

@plehegar
Copy link

From w3c/pointerevents#381

Pointer Events link to 3 places in HTML that are not exported:

cc @patrickhlauke

@plehegar plehegar added anchor permanence Identifies issues opened by other standards organizations, as per WHATWG's anchor permanence policy editorial Changes that do not affect how the standard is understood labels Jun 10, 2021
@domenic
Copy link
Member

domenic commented Jun 10, 2021

html/#task-queue (from The pointerrawupdate event)

Since this is imprecise descriptive prose anyway, I suggest it be replaced with "event loop", so that "task queue" can continue being a HTML-internal concept which we are free to refactor.

html/#initiate-the-drag-and-drop-operation (from drag operation starts)

This is a classic example of monkeypatching. We should not export the operation from HTML so that it can be monkeypatched. Instead, this normative requirement (to fire pointercancel + pointerout + pointerleave, all synchronously I guess) should be moved to the definition of "initiate the drag-and-drop operation".

html/#event-loop-processing-model

Yeah, another monkeypatch. The correct architecture here is trickier, but here's one idea:

  • The pointermove event section gets changed from saying "MUST fire a pointer event... may actually decide not to do the MUST previously mentioned, but instead coalesce on animation frame callbacks" to "MUST either fire a pointer event, or add a pointer event to the coalesced events queue". (Is the queue per-document? Per window? Per UA? Something to define...)
  • The pointer events spec gets a new operation, "fire coalesced pointer events", which drains the coalesced events queue and fires them.
  • HTML gets updated to call the "fire coalesced pointer events" operation.

This will also make it clear where the coalesced pointer events get fired, relative to all the other things that happen during update the rendering (i.e. autofocus, resize, scroll, media queries, animations, fullscreen, animation frame callbacks, intersection observers, paint timing...).

@plehegar
Copy link
Author

plehegar commented Aug 4, 2021

There is a remaining last clarification to make but I believe the issue here could be closed since it's been resolved on the pointer events side. Thank you @domenic for the feedback.

@domenic
Copy link
Member

domenic commented Aug 4, 2021

Hmm. I think there's still work to do here if possible:

  • Update "Fire a pointer event at the source node named pointercancel, and fire any other follow-up events as required by Pointer Events" to reference an actual algorithm that fires the appropriate events. (A minor clarification, but one that still needs work on the HTML side.)
  • Fix the event loop monkeypatch (requires work on both pointer events and HTML sides).

mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
anchor permanence Identifies issues opened by other standards organizations, as per WHATWG's anchor permanence policy editorial Changes that do not affect how the standard is understood
Development

No branches or pull requests

2 participants