<scribe> Scribe: Patrick H. Lauke
smaug: I've not had a chance to look at this yet
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
Patrick: and similarly, will tackle for next meeting
Patrick: as mustaq is on vacation...
liviutinta: he has worked on a web platform test, but is encountering issues with web driver
smaug: need to do some more testing
<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
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 ...
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
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
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
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
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: Patrick_H_Lauke smaug liviutinta No ScribeNick specified. Guessing ScribeNick: Patrick_H_Lauke Found Scribe: Patrick H. Lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2020JulSep/0044.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: olli 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]