<scribe> Scribe: Patrick H. Lauke
from last meeting, specific question if MS has customers still interested in this. MS probably has, but nobody has approached Edge team about it. not a priority for Edge team at this point. did some research on raw input APIs in general, how data from a touchpad can be consumed: a) like a mouse b) like a mouse but differentiated from other mice on the system (might already be solved with pointerlock or similar). there are APIs in windows whic[CUT]
c) Edge kind of has: consuming data from touchpad as a digitizer that maps to the screen, interpreter of gestures, more complex pointer events. in Edge these can relate to the cursor - pinch zoom, two fingers on trackpad interpreted as single pointer to pan page
some interpretation of multiple contacts. Edge kind of had this, but don't believe this is what the issue is about
[different examples, for games for instance, of using raw data of trackpad NOT relative to cursor]
there's certainly potential of using pointer events to hook into these sort of scenarios
(all the above comments from Bo)
Bo: is there an API that can enumerate devices and capabilities (e.g. to find trackpad, its resolution, etc)
Navid: there are limited APIs attached to a pointer, but not an equivalent of "give me all the devices" like you'd get at OS level
do capabilities belong to device, or are they attached to each event
<mustaq> Navid: We can use InputDeviceCapabilities to expose trackpad size (xmax, ymax). But so far it's Chrome-only.
Bo: does pointerlock allow you to specify a specific pointer?
Navid: pointerlock only works for mouse, hides the cursor, and lets you get the data for that
we have pointercapture...
Bo: that only controls target of the events, doesn't disconnect it from the cursor
if we added resolution of trackpad to device capabilities, we could use that for game scenarios
we'd probably need enumeration
Navid: what happens if using
pointerlock and then you touch screen?
... [discussion of various edge cases, whether we perhaps want
to extend pointerlock]
Ella: with pointerlock, only movement counts
Bo: would not be appropriate for
touchpad, don't just want delta movement but coordinate system,
based on touchpad not the screen/cursor position
... thinking in this direction probably has potential, but not
sure if priority
precision touchpad in windows identifies as different types of pointer...mouse, touch, or if you do a gesture...
wouldn't want to lock down the type of the event as a result of this, could be problems with duplicate events or stop saying/lose ability to identify as touch...
Navid: if i do pinch zoom, do i get two different pointers/streams?
Bo: no you get one (it's interpreted by the system before it reaches browser?)
two on the pinch zoom, one on two finger scroll
Mustaq: two different types of interactions...
Bo: rationale we wanted smooth scrolling, and wasn't cancelable
Navid: so panning with two fingers you get wheel events?
Bo: you're going to be receiving single pointer related events
when pinch zoom on precision touchpad you get 2 pointerIds' worth of pointer events
fingers came down wherever the cursor was located
Navid: part of this behavior is in Windows, some in Edge? what is the data that's sent to the app?
do they identify as pen, mouse or touch? or a different type?
Bo: in chrome i think they get modeled down to wheel events, but there's a distinct source there that lets you know that it's a two finger scroll
how browser then models it in JS events it's up to the app to interpret that input source
app = windows app / browser
key point: inventing new pointer type we would associate with trackpad would conflict with the edgeHTML based edge model
Mustaq: we had some issues with android apps on chromeOS
two finger scrolling being different from pinch zoom, some devices sending different events (at OS level?)
Navid: if we were to go with this, how should we expose this info?
Bo: still have open questions...if we're shoehorning it here into PE and it's a good fit. presumes we'd add something to input device capabilities. presumes we'd have pointerlock to be triggered by pointerId...if we have done that...needs more thought
you still calling it on an element and then touchpad behaves differently than previously? or not pointerlock on element but there's a touchpad object and you lock IT
there could be multiple shapes to this API. but cautioning about not adding new pointertype
we shouldn't just add pointertype and call it a day. set of features that need to work together
Patrick: think there's overlap also with Gamepad API (which does have trackpad data stuff, device enumeration), particularly if we are looking mostly at game scenarios. feels like this is a more "we need low-level access to inputs, their capabilities, and accessing raw data" which is outside of the remit of Pointer Events specifically
Navid: how do we move forward? or not?
Bo: should we proceed writing down ideas even without customer? believe we need a customer, then look at API surface area, and then decide where we extend the platform
do YOU have a customer?
Navid: we don't
Ella: we can ask at an upcoming gaming conf
Patrick: still reiterating that this feels far more fundamental, and outside of our scope
Do we want to proceed, or leave this?
Navid: we can contact original poster about more details for this issue?
Mustaq: ... signature on the trackpad as scenario...
Bo: can think of lower level API that can facilitate that. maybe need follow-up next call to see if there's more scenarios. our remit is fairly scoped, so perhaps if we can justify expanding charter or decide to move to a separate group
right now feeling it could be elsewhere and might not be pointer events
RESOLUTION: gather more scenarios in the next two weeks, then decide if we want to take forward
Navid: should we document when browser can/should call pointercancel (?)
and adding a property that says "this event may be cancelled" so app can decide to ignore already/speculatively
should we call out events that can be preventDefaulted / cancelled
Olli: we should probably document the common ones, but can't future proof for any possible behaviours
Mustaq: we list a few in the spec currently ...
Navid: should we have info in PE about how other event types can be prevented, or does that have to be documented elsewhere (e.g. in the dragstart etc definitions)
do we want to expose "this pointer might be cancelled because..."
"this pointer is capable of scrolling, so it may be cancelled if UA decides to scroll"
Bo: today is your method to prevent cancellation restricting pointer action / touch-action?
[discussion on current touch-action limits]
[discussion of slop region, touch-ACTION: pan-x, and what happens if moving Y first then X, or Y, a bit of X, and then Y again - whether events are suddenly cancelled or not]
Bo: two thoughts: about slop region, before leaving the slop region, app might be already responding to events before it leaves, and then jitter when the user does leave the slop region
could do perhaps with some gesture recognition / knowing when user has gone beyond slop region / they are committed. they know when it's not cancellable anymore
that might be helpful
thought two: for things that don't fit touch action model like drag, are we missing some actions?
Navid: there's another issue in github - what if we do long presses and then something else. an avenue to explore, extending touch action.
Bo: nothing in spec now about gesture reconigiton, which is likely a limitation of our charter.
are we missing drag from list of touch actions?
i.e. if UA has built-in drag behavior and we need to prevent it?
Olli: dragging is always preventable via JS or CSS
Bo: maybe just need to document. would you get pointercancel if you didn't write drag handler and preventdefault
Olli: yes believe so
Bo: tell me a list of all things i need to preventDefault on. so might be easiest for us to document this in touch action
Navid: that might be good solution for now. could go beyond - make a list of "here's to prevent drag, here's how to prevent X..."
<smaug> "If the start of the drag operation is prevented through any means (e.g. through calling preventDefault on the dragstart event) there will be no pointercancel event."
Bo: is the question if we need to document, or do we need to extend touch-action
Navid: question was about extending documentation. touch action will need more discussions
Mustaq: see bullet points in the issue, also mentions overscroll
[realises he moved to next issue already]
RESOLUTION: we'll start with a PR to extend prose in spec about cancellation scenarios. Navid/others to collaborate on that by email/GH issue
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/two finger scrolling being different from two finger scroll/two finger scrolling being different from pinch zoom/ Present: patrick_h_lauke Olli_Pettay BoCupp NavidZ Mustaq_Ahmed Ella_Ge No ScribeNick specified. Guessing ScribeNick: patrick_h_lauke Found Scribe: Patrick H. Lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2019AprJun/0096.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]