You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #437, I realized that a section on "state of the input device" would be useful. I came up with this tentative diagram, wanted to check other people's thoughts.
Here are some benefits I can see:
A. Current spec wording indirectly imply such a state hierarchy, but this is not obvious.
B. The open issues (#285, #357, #400) on event ordering could benefit from this.
C. Device-disconnection vs panning/zooming/DnD lead to two different state of the pointing device. This is not mentioned anywhere. Discussion on hoverable stylus gets confusing without it.
D. We may need to clarify the state distinction in [C] even for #203.
E. The spec is silent that touch-pointers cannot be in "active state" outside "active button state". As a result, pointerout/pointerleave events may appear to mark a transition to inactive state which is clearly wrong.
The text was updated successfully, but these errors were encountered:
@mustaqahmed, the pointer captured state in the tentative diagram doesn't agree with my understanding of pointer capture. In particular it suggests that pointer capture is lost before the active button state is lost which means you wouldn't be able to capture up events. I think the capture loss should be deferred until the active state.
Hmm, fair point about capturing pointerup. Can we perhaps say that in this case the pointerup event forces the implicit release after hit-testing is done so event target is not affected by this state change?
I think logically we cannot be in the captured state without being in the active button state, but the other way around is possible. Current spec wording seems to support this notion by allowing explicit capture only from within the active button state, right? If we don't have this state vs sub-state hierarchy, "active button" vs "captured" would be two partially-overlapped states which IMHO is one source of the complicated event ordering discussions.
While working on #437, I realized that a section on "state of the input device" would be useful. I came up with this tentative diagram, wanted to check other people's thoughts.
Here are some benefits I can see:
A. Current spec wording indirectly imply such a state hierarchy, but this is not obvious.
B. The open issues (#285, #357, #400) on event ordering could benefit from this.
C. Device-disconnection vs panning/zooming/DnD lead to two different state of the pointing device. This is not mentioned anywhere. Discussion on hoverable stylus gets confusing without it.
D. We may need to clarify the state distinction in [C] even for #203.
E. The spec is silent that touch-pointers cannot be in "active state" outside "active button state". As a result,
pointerout
/pointerleave
events may appear to mark a transition to inactive state which is clearly wrong.The text was updated successfully, but these errors were encountered: