Meeting minutes
<smaug> just a second..
Touch Events CG
Patrick: just a small note to say that the group aim/description has now been updated - mostly pointing back to us
Explain relation of coalesced events to parent event https://github.com/w3c/pointerevents/pull/440
Olli: the "As a result..." is a bit weird, but otherwise it's ok
Mustaq: concern about "events" vs "event types"
Flackr: how about we merge this now and can always tweak wording later
Patrick: should we merge?
<mustaq> Sounds good
[all agree]
Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356
Patrick: i added this to the agenda, but wasn't sure if there actually had been action over last two weeks, or if this a more long-running action
Olli: question about whether there's always a click after the up (?)
Flackr: one option is to retain pointer capture until it's determined if a click is fired
Olli: wonder if this would affect something else. hopefully nobody is mixing pointer and mouse events, as that may cause issues
Olli: but maybe it's ok. fire lostpointercapture when we know click won't fire so we don't need to capture anymore
Olli: only for implicit release
Mustaq: what about double-tap?
Flackr: depends if it results in zoom
Flackr: if double-tap to zoom is disabled, each tap will be an independent event
Flackr: and i think that's consistent with mouse behavior
Flackr: because you get implicit capture release on click ... and if you had an explicit capture, it'll be released on the first...
Olli: click is odd because it's not user input, but reaction to the "up"
<smaug> (btw, I'll need to leave 15 min early today)
Olli: what else do we need here? was starting to look at our code
Flackr: think we're in agreement that it should behave this way: without releasing capture explicitly, it should be released implicitly when determined that there won't be a click
Mustaq: when touch is not canceled, it will fire a click...
Patrick: so what's outcome?
Flackr: change to the spec to reflect what we discussed, tests
Olli: would be good to have one implementation to check we didn't overlook something
Olli: and tests
Olli: this will then hopefully address #356 and (maybe) #357
Flackr: I think so
ACTION: next steps for #357 to find an implementation/test
Mustaq: I don't think we have chrome bugs for this, but need to investigate. changes for both touch and mouse
Olli: same in firefox
Defining event orders through a "state of the input device" https://github.com/w3c/pointerevents/issues/438
Mustaq: i think I got something wrong on this, so let's close this bug. think the state diagram was more confusing than helpful
ACTION: close issue
Patrick: let me just look over other issues not tagged as v3 ... https://
Patrick: nothing there tagged "future" that we want to tackle for v3, so think we're good
Mustaq: what timeline are we looking at for going to REC for v3?
Patrick: i'm not in any particular rush, but will confirm with Philippe Le Hegaret about best timings. if i remember right, our group's charter still has ample time (not like last time where we needed extension to push through v2). I'm going to guess October or something this year? as for having implementations, I'm sure there's some leniency even if not rolled out, particularly as we're not talking about a whole new feature, but
just a refinement of event order. even just an agreement in principle that two implementers are working on it actively should be fine, even if tests currently fail (in implementation report)
Olli: question about whether we carry on with these meetings, now that the last outstanding item is this longer-running implementation question. find it quite useful as a bit of a motivator to push things through, having that scheduled meeting
Flackr: agree, good to have meeting just as a reminder to do things
Patrick: happy to keep these meetings going every two weeks more as a "heartbeat" / status meeting until we've published v3 REC
[group agrees]
Patrick: thank you all, speak to you again in 2 weeks' time