- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 26 Jun 2019 17:31:18 +0100
- To: public-pointer-events@w3.org
Dear all, minutes from today's call available on https://www.w3.org/2019/06/26-pointerevents-minutes.html and copied below: PEWG 26 Jun 2019 Agenda Attendees Present patrick_h_lauke, Olli_Pettay, BoCupp, NavidZ, Mustaq_Ahmed, Ella_Ge Regrets Chair Patrick H. Lauke Scribe Patrick H. Lauke Contents Topics Extend pointer events to support raw trackpad data <https://github.com/w3c/pointerevents/issues/206> (Update from Bo) Too many other behaviors interrupt pointer events (dragstart, touch-action)<https://github.com/w3c/pointerevents/issues/213> Summary of Action Items Summary of Resolutions <scribe> Scribe: Patrick H. Lauke Extend pointer events to support raw trackpad data <https://github.com/w3c/pointerevents/issues/206> (Update from Bo) 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 Too many other behaviors interrupt pointer events (dragstart, touch-action)<https://github.com/w3c/pointerevents/issues/213> 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 Summary of Action Items Summary of Resolutions gather more scenarios in the next two weeks, then decide if we want to take forward we'll start with a PR to extend prose in spec about cancellation scenarios. Navid/others to collaborate on that by email/GH issue P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 26 June 2019 16:31:44 UTC