Minutes from Pointer Events WG call 19 August 2020

Dear all,

minutes from today's call are at 
https://www.w3.org/2020/08/19-pointerevents-minutes.html and also copied 
below:

PEWG
19 Aug 2020
Agenda 
https://lists.w3.org/Archives/Public/public-pointer-events/2020JulSep/0044.html

Attendees
Present
Patrick_H_Lauke, smaug, liviutinta
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

* 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

* Click event while a pointer event is captured 
https://github.com/w3c/pointerevents/issues/75

* Should DragEvent be upgraded to a PointerEvent? 
https://github.com/w3c/pointerevents/issues/106

* Explore unifying web-platform-test automation logic 
https://github.com/w3c/pointerevents/issues/120

* Change the type of click, auxclick, and contextmenu to PointerEvent 
https://github.com/w3c/pointerevents/pull/317

* Standardize CSS pseudoclass behavior for touch 
https://github.com/w3c/pointerevents/issues/123

* How to determine when a tap is impossible 
https://github.com/w3c/pointerevents/issues/124

* How best to inflate hit targets for touch? 
https://github.com/w3c/pointerevents/issues/126

<scribe> Scribe: Patrick H. Lauke

Changing the DOM hierarchy while handling a "pointerenter" event 
produces significantly different results across browsers 
https://github.com/w3c/pointerevents/issues/285#issuecomment-662547965
smaug: I've not had a chance to look at this yet

touch-action and scrolling directional lock 
https://github.com/w3c/pointerevents/issues/303
liviutinta: on previous topic, i've been working on web platform test 
(linked from issue)

<smaug> is it https://github.com/web-platform-tests/wpt/pull/24954?

and i have another case to test similar to that

Patrick: on my topic, not had a chance to tackle this as i was on 
vacation. will address for next meeting

The behavior of `touch-action: none` on <iframe> is unclear 
https://github.com/w3c/pointerevents/issues/325
Patrick: and similarly, will tackle for next meeting

setPointerCapture should be disabled in sandboxed iframes by default 
https://github.com/w3c/pointerevents/issues/16
Patrick: as mustaq is on vacation...

liviutinta: he has worked on a web platform test, but is encountering 
issues with web driver

Click event while a pointer event is captured 
https://github.com/w3c/pointerevents/issues/75
smaug: need to do some more testing

Should DragEvent be upgraded to a PointerEvent? 
https://github.com/w3c/pointerevents/issues/106
<smaug> https://html.spec.whatwg.org/#the-dragevent-interface

Patrick: wondering if this is something that affects PE spec directly, 
or if it needs to be tackled in UI events or similar

smaug: it's in html spec, and there it inherits from mouse event

so yes, it's an html spec issue

Patrick: does someone want to prod them?

smaug: i can at least file an issue so people see the discussion

<scribe> ACTION: Olli to file an issue against HTML spec

Explore unifying web-platform-test automation logic 
https://github.com/w3c/pointerevents/issues/120
smaug: and I just filed the HTML spec issue already

liviutinta: i'm not completely familiar with WPT, but while writing 
tests, there are actions for pointerup, pointerdown, etc.

and we're still working on it

smaug: I think this was from a time before web platform tests has any 
low level events

liviutinta: you still have to include vendor file(s), but i'm not sure 
if this is more involved than that or not

need testdriver-vendor.js. if this issue is about having tests even 
without testdriver-vendor.js, then it's still open

smaug: i guess that's fine even having that js file

as far as i can see in gecko we have that file, but it's empty

liviutinta: we do have code in ours

Patrick: so we happy closing this, as this is more a meta-issue not about PE

smaug: things have improved, used to be a lot more work / 
browser-specific stuff. but that's not the case anymore

we should close this issue and ask people to file WPT / webdriver 
issues, whichever is the more relevant repo

Patrick: makes sense to me, closing

that's all the issues i had earmarked. we have one hanging pull request ...

Change the type of click, auxclick, and contextmenu to PointerEvent 
https://github.com/w3c/pointerevents/pull/317
liviutinta: on this we are running an experiment until end of august. 
not heard anything back, but i'll have to check

Patrick: ok, leaving open until we know what outcomes are

Standardize CSS pseudoclass behavior for touch 
https://github.com/w3c/pointerevents/issues/123
Patrick: wondering if we should chuck this as is to CSS WG? Rick 
mentions setting up some WICG incubation. either way this seems it's 
outside of PE spec directly.

<smaug> https://drafts.csswg.org/selectors-4/#active-pseudo

Patrick: should we defer this to CSS WG, as issues about when/whether 
:active applies to touch (though this is scary territory due to browser 
heuristics / IPR)

smaug: i can file an issue in github for CSS WG, and we keep our issue open

<smaug> https://github.com/w3c/csswg-drafts/issues/5454

Patrick: this will also apply to touch events, so not just PE. leaving 
issue open to see what initial reaction is

How to determine when a tap is impossible 
https://github.com/w3c/pointerevents/issues/124
Patrick: to me this is once again an issue that touches on browser 
implementation/potentially has IPR concerns.

smaug: let's wait and see what the outcome of #123 is - maybe, depending 
on that, we can/should just add a line about not firing event when 
:active, or something to that effect

How best to inflate hit targets for touch? 
https://github.com/w3c/pointerevents/issues/126
Patrick: this again feels like UA specific

smaug: and the whole hit testing, even for mouse events, is unclear

Patrick: i see in the cross-referenced issue against touch events 
https://github.com/w3c/touch-events/issues/93#issuecomment-384822302 
that Jacob Rossi specifically mentioned this aspect as being out of 
scope for PEWG at the time

for that reason, I'd say we close this (and don't touch it with a barge 
pole)

Patrick: good stuff, we managed to close a few old issues. For next 
time, let's carry on with the actions from last time, which are:

* 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 to reach out to graouts and gary

* Click event while a pointer event is captured 
https://github.com/w3c/pointerevents/issues/75 > assigning issue to Olli 
to research further

* touch-action and scrolling directional lock 
https://github.com/w3c/pointerevents/issues/303 > patrick to review/add 
note to spec

* The behavior of `touch-ACTION: none` on <iframe> is unclear 
https://github.com/w3c/pointerevents/issues/325 > patrick to review/add 
note about unintuitive behavior

* setPointerCapture should be disabled in sandboxed iframes by default 
https://github.com/w3c/pointerevents/issues/16 > mustaq to look into the 
current state of play and comment on the bug

Patrick: foreshadowing this for next time - one issue that's fresh and 
we should look at is this

https://github.com/w3c/pointerevents/issues/328

"Specify exactly how event coalescing works"

nothing to do just now, but forewarning that we'll want to talk about 
this next time most likely


-- 
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

Received on Wednesday, 19 August 2020 15:51:18 UTC