- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 16 Sep 2020 17:02:16 +0100
- To: public-pointer-events@w3.org
Dear all, minutes from today's call are at https://www.w3.org/2020/09/16-pointerevents-minutes.html and also copied below: PEWG 16 Sep 2020 Agenda https://lists.w3.org/Archives/Public/public-pointer-events/2020JulSep/0062.html Attendees Present Patrick_h_lauke, plh Regrets Chair Patrick H. Lauke Scribe Patrick H. Lauke Contents Topics * Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285#issuecomment-662547965 Click event while a pointer event is captured https://github.com/w3c/pointerevents/issues/75 touch-action and scrolling directional lock https://github.com/w3c/pointerevents/issues/303 The behavior of `touch-ACTION: none` on <iframe> is unclear https://github.com/w3c/pointerevents/issues/325 setPointerCapture should be disabled in sandboxed iframes by default https://github.com/w3c/pointerevents/issues/16 Stylus eraser: should it be a new pointerType instead of a button state? https://github.com/w3c/pointerevents/issues/134 Mouse back/forward buttons: page navigation or JS events? https://github.com/w3c/pointerevents/issues/191 <scribe> Scribe: Patrick H. Lauke <smaug> probably late a minute or two looking at actions from last time we met Should DragEvent be upgraded to a PointerEvent? https://github.com/w3c/pointerevents/issues/106 * Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285#issuecomment-662547965 Olli: reviewed the algorithm, looks good, but need feedback from Chrome pointerenter/mouseenter interleave, Safari does, but firefox and chrome don't do that currently if safari has managed to ship with this behavior, it's web compatible Olli: so the question is are we all ok to change behavior to match https://github.com/w3c/pointerevents/issues/285#issuecomment-693405103 <scribe> ACTION: for Google to review this as well, decide if we're happy with this Patrick: so i assume this then needs normative change in the spec? Olli: yes the nice thing is that this will have hooks for our spec to point to Click event while a pointer event is captured https://github.com/w3c/pointerevents/issues/75 Patrick: olli you still ok to research this? Olli: yes, will do for next meeting touch-action and scrolling directional lock https://github.com/w3c/pointerevents/issues/303 Patrick: this was for me to review/add note to spec if needed. not got around to it yet, will do though The behavior of `touch-ACTION: none` on <iframe> is unclear https://github.com/w3c/pointerevents/issues/325 Patrick: similarly, not had much time on this Olli: have been testing that today, see similar behavior in Chrome and Firefox mobile ... pointer-events (CSS) affects the hit-testing it's confusing, agreed, but perhaps the confusion is pointer-events (CSS) for reaching into the iframe Patrick: so is Safari behaving the other way <smaug> https://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty <smaug> https://svgwg.org/svg2-draft/interact.html#PointerEventsProperty Olli: no the way I understand is that Safari behaves the same way as Chrome/Firefox, it was their test that was based on the wrong expectation if all browsers behave the same, maybe we need to leave this as is but just make sure it's documented SVG spec doesn't seem to provide good explanation for pointer-events (CSS) on why it behaves the way it does "given element does not receive pointer events" but doesn't explain about the content of the iframe Patrick: so it sounds like we do need at least a note that explain the unintuitive touch-action behavior, that it doesn't affect the handling inside the iframe will see if there's a natural place for this, though it's very specific edge case <scribe> ACTION: Patrick to add note about touch-action and iframe setPointerCapture should be disabled in sandboxed iframes by default https://github.com/w3c/pointerevents/issues/16 Philippe: I think from a security point of view, we can wait until we get the review from security group especially since last they looked at it 2 years ago and privacy landscape changed, so won't hurt anyway to get them to have a look again Patrick: closing this, with understanding that as it's in the security tracker, we'll get this flagged again if it's a concern. Stylus eraser: should it be a new pointerType instead of a button state? https://github.com/w3c/pointerevents/issues/134 Olli: there was a proposal from microsoft Patrick: https://msdn.microsoft.com/en-us/library/windows/hardware/mt604235(v=vs.85).aspx <smaug> https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/324 Patrick: the msdn one has the "In Range (Intent to Erase)" Olli: think there needs to be some generic API for better pen handling in general Patrick: not seeing appetite for adding pointerType="eraser". current state is you can't distinguish hovering pointer and hovering eraser Olli i can ask Bo what the status is with Microsoft proposal is <scribe> ACTION: Olli to reach out to Bo about the other spec PLH: (reminds us of the charter running out end of this year, and planning around what we want to do next) Suggest for next meeting also explicitly inviting Microsoft to come and talk to us about the other spec and plans they may have around that Mouse back/forward buttons: page navigation or JS events? https://github.com/w3c/pointerevents/issues/191 Patrick: a fairly old one, just to get conversation started on this one. need to think if we need/want to do anything specific here (or if it's more in UI events court) Olli: yes, this is more UI Events, i think no one filed a UI events issue Patrick: would you like to do it Olli Olli: yes i'll do it <scribe> ACTION: Olli to file UI events issue for https://github.com/w3c/pointerevents/issues/191 Patrick: if there's no other business, suggest we adjurn for today. Usual reminder to ideally go through issues in https://github.com/w3c/pointerevents/issues and see if there's anything outdated or low hanging fruit that we can close <smaug> oh, yes, I have found the browser which works with webex on Linux. It is Nightly. I can both join _and_ leave a meeting :) :) Thank you all Summary of Action Items [NEW] ACTION: for Google to review this as well, decide if we're happy with this [NEW] ACTION: Olli to file UI events issue for https://github.com/w3c/pointerevents/issues/191 [NEW] ACTION: Olli to reach out to Bo about the other spec [NEW] ACTION: Patrick to add note about touch-action and iframe -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke -- Inclusive Design 24 (#id24) https://inclusivedesign24.org
Received on Wednesday, 16 September 2020 16:02:31 UTC