- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 12 Jun 2019 17:07:59 +0100
- To: public-pointer-events@w3.org
Thank you all for attending. Minutes from today's call at https://www.w3.org/2019/06/12-pointerevents-minutes.html and copied below: PEWG 12 Jun 2019 Agenda Attendees Present patrick_h_lauke, Olli_Pettay, Navid_Zolghadr, Bo_Cupp, Mustaq_Ahmed, plh_ Regrets Chair patrick_h_lauke Scribe patrick_h_lauke Contents Topics Summary of Action Items Summary of Resolutions <scribe> Scribe: patrick_h_lauke <smaug> am I the only one on the call? <smaug> nope here now :) https://lists.w3.org/Archives/Public/public-pointer-events/2019AprJun/0064.html <NavidZ_> the first item is <NavidZ_> https://github.com/w3c/pointerevents/issues/100 <NavidZ_> Should "click", "dblclick" and "contextmenu" events be PointerEvents? Bo: outstanding item was what are use cases. posted use cases we had in edge, differentiate user experience for things like select control so depending on how it's opened (mouse/touch) it displays it different (spaced differently) ... also found article by Chris Wilson from HTML5Rocks / UI practices hover-behaviors/click-behaviors different user experience by pointer type. developers ask questions about it. making actual click etc pointer event would avoid authors having to hack this themselves by listening to pointerdown counter argument: behavior in edge (for the select spacing) triggered on pointerdown rather than click would not be difficult for users today to track pointerType when PE come in, and remember that for the click motivation in short: want to differentiate UX based on pointer type next steps? Navid: compat risk of changing existing events wonder how we would treat other events like drag events, mouse events themselves pointerType and pointerId only perhaps, as others would just be zero/default? for drag there were also problems Olli: this is the bug https://github.com/w3c/pointerevents/issues/106 even riskier and trickier, make drag events inherit pointer events which inherit mouse events click is also dispatched for keyboard, don't know what edge uses for pointerType in that case Navid: what would the pointerType of a click be if triggered by mouse Patrick: "click" is treated a bit like generic "activate" and keyboard wouldn't make sense to have a faked pointerType Mustaq: question about the spacing/select use case - should we not use CSS MQ interaction queries? Patrick: weary of that, as they use whatever brower/OS consider the "primary" input. should really go by what user ACTUALLY is using Mustaq: ok, use cases seem valid then Bo: what would compat risk be to add pointerType field to click, doubleclick, etc events would problem be authors having defined a custom property that would clash? enumerating properties? Navid: compat risk should be minimal but changing the whole type and hierarchy of events will be compat risk for sure Mustaq: and adding new field to click event seems bad because it's not a pointer Navid: to clarify, we want to add pointerType to the Mouse Events definition Olli: would make it simpler to fix drag event issue as it inherits mouse event stuff already Navid: need to check if it's possible to have pointerType in both Mouse Event and Pointer Event model might need to change where this is defined? Olli: do we want to call it something else? and do we want/need to decide what keyboard should generate in terms of pointerType? should it be called inputType? Patrick: i think that would go outside of our remit/scope to define what keyboard does/doesn't Bo: original idea was that PE was going to replace mouse events. not sure if that's still the view in the larger PEWG so expanding the definition of mouse events seems to go counter to that Navid: i share the same idea, but can't see mouse events disappearing. and yes, adding/enhancing mouse events will go against this Bo: so should we leave click etc alone and wait? should we try to upgrade events like drag, making it inherit from PE, and demonstrate it's safe? Navid: making click, doubleclick etc actual PE would help towards our ambition/goal Mustaq: we also have issue of fractional coordinates in PE vs integer coords for mouse events Navid: do we have data on any breakages? ... so upgrading/changing click, doubleclick etc to PE may cause issues as coords then go fractional ... we could try to just tackle click, doubleclick, contextmenu and leave mousemove etc alone. could be less breaking (with things like fractional coords) Bo: I can imagine breaking changes just for apps that present/show coords, so you may now get overflow because of the fractional. my hunch would be breaking change with real compat impact, but have no data Mustaq: ... we could try to just change click to use fractional in canary Navid: not just about coords though, it's about making it click a full PE with all the other attributes, AND fractional coords maybe we should ship and try and see what breaks, suspecting it might be a small percentage Olli: but what are the benefits? the most useful is just the pointerType / inputType doing the full "make click a PE" feels very risky for no extra gain Mustaq: only useful things for use cases mentioned is pointerType no use case for pointerId Olli: for JS dev point of view won't matter, they won't look at prototype chain Bo: think it helps us keep model, PE superset could be future scenarios where things like pressure on a mouse may also be there but doesn't help the case of seeing PE as the future to backfill mouse events i think i hear everybody saying we should use PE and see what the actual compat risk is Olli: seems minimal gain for too big potential for breaking sites Navid: to gauge compat risk best way is to enable the change in chrome canary/dev and see what comes back Mustaq: not sure if we get enough feedback/use though on those Navid: ...at some point we need to accept some kind of breakage... extra info on click seems to be useful, even if minimal enough incentive for us to go and experiment Patrick: maybe the larger question of should click, doubleclick, contextmenu even be mouse events? it's historical, but should really be "activate" for instance, as they get fired by keyboard too Navid: could see at TPAC the input events group Bo: jQuery relies on click being a mouse event, so would break Navid: if we were to switch click etc to PE, and assuming we can ensure no compat problems, what would we do for keyboard? [discussion about activation with a keyboard (enter, space, context menu button) not being a fake mouse event, but actually firing things directly in browser based on where the keyboard focus is] Bo: so where does that leave us, seems it doesn't seem appropriate treating click as a full PE, but perhaps look at inputType backfilled into click as a more generic activation event Olli: ...and we're not the people who can decide to add things to mouse events or click, we need to speak to UIEvents folks Bo: can we decide between "click as PE" or "go talk to UIEvent folks" Navid: did we decide if click as PE what happens with pointerType to keyboard activation? Patrick: i'd be good with leaving pointerType empty on keyboard, instead of inventing our own for keyboard OR pretending it's a mouse when it isn't. same for future when activating via voice or similar, we don't want to invent these... Mustaq: can we just try moving click to UIEvent? Olli: need coordinates Navid: also modifier keys etc. so can't just move it higher Either move click down hierarchy (making it a PE) or adding more properties like pointerType to mouse events or whatever in all cases we need to speak to UIEvents folks should we just try though to see what happens to inform our decision scribe: setting pointerType to nothing for anything other than mouse/pen/touch works for now Mustaq: so what kind of experiment? Navid: can land behind a flag (experimental web plat features) and see if we get bugs Mustaq: so what are we trying? Navid: making click, doubleclick, contextmenu a PE and see what happens (behind the flag) Mustaq: we'll have to tweak our tests that expect integer coordinates Navid: let's be aggressive, set pointerType to null for things like kbd, and see what happens Patrick: do we want to talk to UIEvents folks already in parallel, or wait until we get data back from this experiment? Navid: can bring up with them already, but likely having data will be helpful to inform issue / face to face at TPAC Patrick: who wants to talk to UIEvents folks then? Navid: I can do that Patrick: time check - 4 minutes to the hour. Still ok to reconvene in 2 weeks time, or need a call earlier? Navid: seems 2 week cadence is fine, this topic was quite a chunky one Patrick: and lastly, do we want to proceed, in a branch perhaps, to merge PE extension to PE v2 to see what the PE v3 will look like once they're merged? Navid: waiting for TAG review to complete. should we do that now or wait? Patrick: probably makes sense then to wait for tag review, THEN merge the thing in a branch, and then check what the process is with Philippe (if we simply overwrite the gh-pages, or if it needs to first get changed in metadata etc) ... 2 minutes to the hour, so let's adjurn. Back in two weeks. -- 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, 12 June 2019 16:08:24 UTC