Re: [w3ctag/design-reviews] Pen Events API (#553)

I agree with @cynthia that it sounds weird to have a separate set of events for button presses when the Pointer Events deliver those (and if they don't fit the bill, we should expand these). I believe the reason Microsoft went this way is because the Surface Pen delivers its events not only through the digitizer but also with bluetooth when not in range with the screen (for the buttons/gestures they're talking about). And I'm assuming that when not in range the events are probably not coming through standard window message (WM_POINTER_DOWN etc) thus why they thought on an additional API because the underlaying API requires to create a separate connection.

Today as far as I can remember in Chromium, Pointer Events are delivered when the pen/stylus is able to communicate with the digitizer but that's an implementation limitation, I don't think it's written anywhere that pointer events could not be dispatched even if the stylus isn't in range with the digitizer. Now of course if we start to dispatch pointer events just for button state changes it begs the question of what would be the values of the other Pointer Events attributes provided we have no way to fetch them until the stylus is in range with the digitizer (e.g. position, tilt, pressure etc). Maybe we could add an attribute to the events to represent whether the stylus is in range with the digitizer. This would make quite clear that the values depending on being in range will be set to 0. That way you could still propagate the button state changes.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/553#issuecomment-989252077