Additional definitions exports for Pointer Events

[plehegar]

From w3c/pointerevents#381

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

• html/#task-queue (from The pointerrawupdate event)
• html/#initiate-the-drag-and-drop-operation (from drag operation starts)
• html/#event-loop-processing-model | animation frame callbacks: not sure if we need a hook for step 12 (from animation frame callbacks)

cc @patrickhlauke

[domenic]

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]

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]

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).