Meeting minutes
<smaug> now, let's see if webex has been fixed.
<smaug> It didn't like some the user agents with >= 100 version number
Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356
Patrick: I think last we looked at this, Olli wanted this to be verified on Google side
Rob: on mobile, touch has implicit capture, which is why it fires the click...
Olli: Chrome isn't consistent with itself between desktop and mobile. would prefer consistency, or if there's a good reason to explain the difference
Rob: on mobile safari it seems that capture has not influenced the event stream at all
Rob: we could consider this a bug. in the period before we generate click you can't have other events. click is sent async (because of double-tap to zoom), but i don't think you can get other pointer events until the UA has figured out if there's another click coming or not
Rob: we could treat the current behaviour as bug, and say it should be delayed until the UA has resolved whether it's a click or not
Olli: also option to change desktop chrome behavior to fire lostpointercapture after pointerup before click. that would bring consistency
Rob: is the event target correct?
Olli: that's separate bug #357 and this would solve it
Rob: i believe target should be captured node until you release it
Rob: sorry, that's current behavior, common ancestor
Rob: fundamentals and dev expectations, two trains of thought: 1) you captured the event, you never released capture, you expect the click on the element where you captured
Olli: so we postpone, and we also postpone click targeting
Rob: it's dispatching to the common ancestor. suppose the click may not be retargeted. desktop chrome behavior is still doing the click target of the common ancestor
Rob: but if you assume that click is fired while captured, should a captured click fire to the captured node rather than the common ancestor?
Olli: yeah maybe that's you'd expect
Olli: behavior that no browser has right now
Olli: which might be fine since they're all doing different things right now
Rob: it's different, and pointer capture not used on every page
Olli: we had a moz-internal bug, but can't recall any other bugs about this issue. so maybe all web devs are using a library that handles all these cases, or maybe people aren't using it so much
Patrick: i'm guessing from my own experience that devs may only be using it for simple things as it's a new concept. things like doing sliders and not having to attach/remove listeners to body anymore
Olli: so to proceed. fire click on the captured target, and releasepointercapture after click
Olli: and then look at getting browsers to implement
Rob: especially as we consider click a pointer event, it makes sense for click to be captured
Olli: maybe we can take a look at implementations, and see if we go with this approach if there are any more tricky edge cases, particularly on mobile
Rob: should be doable, but will be complexity in making sure that we fire the capture release properly even if the click doesn't turn out to be a click (double-tap to zoom)
Patrick: do we need to also say something about touch-action or is that implicit?
Rob: implicit, don't need to mention. up to UA to know that a click can be processed right away if touch-action doesn't allow double-tap-to-zoom
Olli: contextmenu ...
[quick overview of when contextmenu is fired. after mouseup on windows, on mousedown on other platforms]
Olli: if you capture pointer, and expect context menu, what happens? do you lose pointer capture?
Rob: yes you should lose it
Olli: what if you call preventDefault for contextmenu?
Rob: then you shouldn't
Rob: makes me wonder how a dev would handle right-click dragging
Olli: would just preventDefault contextmenu and handle it as usual
Patrick: would any of you like to make a stab at specifying?
Olli: need to test first how feasible it is
Rob: changing target on desktop shouldn't be a problem, mobile case / timing of releasing pointer capture will be trickier
Olli: and see if the latter leads to some odd behaviors
Patrick: suggest adding a comment on the issue to sum up what was discussed
ACTION: explore feasibility of implementing proposed behavior from issue, think about possible edge cases that might arise
Clarify that coalesced events list contain also a clone of the parent event https://github.com/w3c/pointerevents/pull/436
Patrick: I dropped a super-naive comment on that, see if that makes any sense
Rob: can't be a copy/clone because of potential resampling issue (e.g. different accuracy/rounding of coords)
Rob: coalesced events list represents closest thing to raw events, parent event is the closest thing that the UA decides best represents that list of raw events
Rob: rather than saying "all of the events that were coalesced into this event", should we say "list of all the events since the last event was dispatched", as that implies that it's inclusive
Olli: and then need to say that parent event was generated based on that
Patrick: so you'd never get an empty list (unless untrusted, because there it's up to dev)
Rob: and then add a note in simple language for devs "what this means is that you either go by parent events, or coalesced events. don't mix and match/combine"
[some wordsmithing/suggestion while looking at https://
Olli: we should also still say something about movement
Rob: if you want i can try and have a go at this
Olli: it should only be a couple of very short complicated sentences
ACTION: Rob to make a new pull request to supersede #436
Defining event orders through a "state of the input device" https://github.com/w3c/pointerevents/issues/438
Olli: is this mostly editorial?
Patrick: looks like it wants to clarify what's implicit
Rob: the diagram doesn't agree with my understanding of capture https://
Olli: wondering if this is needed for v3 or we can leave for after
Rob: i think it's useful to define. difference between device that isn't *present*, and one that is just inactive (?)
Rob: would be good to define this, helps explain what happens when an alert from the browser is fired etc
Patrick: suggest asking mustaq to flesh this out some more. Rob if you don't mind adding comment on the issue about it not quite gelling with your understanding of capture. But yes if this turns out to open up a big pandora's box, we can always defer until after v3 is out
ACTION: mustaq to propose some more fleshed out wording
Patrick: thank you all, catch you again in 2 weeks' time