Meeting minutes
Remove should from boundary events note and move to normative must https://github.com/w3c/pointerevents/pull/419
pull request in relation to https://
mustaq: [paraphrased] can we be slightly more explicit instead of just pointing to UI-Events?
flackr: i could add that browser should treat captured event as if the pointer/mouse had been moved to that particular element...
flackr: i can make a change to the PR though if you leave a comment
Patrick: yeah if you want to sort it out in github directly, once we're all happy i'll merge it
ACTION: mustaq/flackr/smaug to tweak PR, once ready for merge let Patrick know
Why is 'touch-events: pan' not a value? https://github.com/w3c/pointerevents/issues/420 (new)
mustaq: does touch-action:pan not map to touch-action:manipulation ?
Patrick: not quite, as manipulation allows continuous zooming
https://
Patrick: i think adding touch-action: pan as a shorthand for touch-action: pan-x pan-y makes sense, doesn't need any further differentiation/explanation
Patrick: the compat spec defines additional touch-action: pinch-zoom but we can't touch that here for ... reasons
Oli: concerned about adding this for v3, should it be future?
Patrick: agreed, let's mark this as after v3, as otherwise currently we have zero implementation on this
flackr: should we also have something about logical direction values?
Patrick: i believe we have an open issue for that https://
flackr: this will make sense once we get support for logical overflow directions
Patrick: that issue also marked future, to be considered once v3 is out
ACTION: keep track of issue for future
How is pointer event ctor supposed to work when coalescedEvents is passed using the PointerEventInit https://github.com/w3c/pointerevents/issues/223
Patrick: wanted to get a sense if we should just park these issues or if they're blockers for v3
Oli: i think chrome implementation did something really weird, in firefox it's different weird...
<mustaq> https://
flackr: we expanded spec since then
mustaq: does the wording in the spec currently make it good enough (regarding trusted/untrusted events and their initialisation)
<flackr> Existing spec text has "Untrusted events have their coalesced events list initialized to the value passed to the constructor"
Oli: need to write some tests...
Oli: but spec might be specific enough now
Oli: we can close the issue now, i'll write tests but that's separate from issue
Patrick: i see comments from AnneVK about filing issues against DOM though, are they now obsolete?
Oli: ah right, that still needs to be tweak how constructor works
ACTION: Olli to look at remaining constructor work for #223
Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285
mustaq: this is really an issue more about UI Events than anything else, but the spec is silent about it too
Patrick: but the ball is fundamentally in their court, so should we close this here as it's something that won't just affect pointer events, but mouse etc as well
mustaq: Gary mentioned at TPAC about PE hooks, I promised I'd look at this for the algorithm
Olli: not sure how algorithm maps to webkit here, but we can review the algorithm first and then see if we need to do anything in PE spec
Patrick: is this a blocker for v3? of mark as future?
mustaq: the algorithm has been going for months, so not imminent release. so shouldn't block v3
ACTION: mark issue for future, so as not to block v3. mustaq to discuss with Gary about algorithm
touch-action:none and overflow:auto https://github.com/w3c/pointerevents/issues/319
[discussion on what the issue is actually about]
flackr: i suspect the gecko behavior is right. we treat scrollable as always scrollable regardless of ancestor touch-action, and scrolling one can lead to scroll chaining...we can recommend that authors put overscroll behaviour to the container with touch-action:none to prevent that behavior
Patrick: if we think about this for the next two weeks and at next meeting decide what to do (if we need to add something to spec to cover these edge cases)
flackr: there are other situations like with position:sticky
ACTION: review #319 for next meeting and see then if we can/should add extra wording to spec for this
<flackr> position:sticky refers to the nearest ancestor scrollport https://
Patrick: thank you for joining. see you all in 2 weeks' time for next meeting