Meeting minutes
‘Logical’ values for the ‘touch-action’ property w3c/pointerevents#505
[group discusses the proposed touch-action values, and whether or not they make sense - i.e. does pan-inline-start mean moving towards, or away from, the inline-start. same issue arguably with left/right/etc. group agreed it *may* be clear enough as is]
mustaq: what happens if writing mode/direction changes in a child, and you start panning on that. does it affect it?
[further explanation/discussion]
Rob: it should be irrelevant if a child changes writing mode, what counts is the writing mode of the element that has touch-action
Patrick: in my head, it makes sense to just look at the one where you defined the touch-action explicitly
Olli: it may be counterintuitive though, if I specified a certain touch action, and then one of the children changes writing mode/direction
Rob: is touch-action inherited? I didn't think it is...
[group checks and confirms it's not inherited]
Olli: it's confusing / complex, like selection
Rob: feel strongly about it, also keeping it simple
PAtrick: so taking a step back, do we want this in Level 3? obviously there's no actual implementation, but just to get a sense if we decided, would browser engines even be amenable to implementing this? can mark as at risk, but we'd need some idea if we can realistically get it into engines
Rob: if it works the way i think it should, then it shouldn't be too difficult to implement for Chrome
[some discussion on if this were living standard there would be slightly less pressure]
ACTION: group to further review w3c/
Triage unlabelled issues https://github.com/w3c/pointerevents/issues
Patrick: in short, for next time, let's make sure we label all new issues to see if it's something we can do easily now, or need to defer to future
ACTION: group to look at unlabelled issues for next meeting and add relevant labels/comments
Multi-pen support and persistent pointerId #353 w3c/pointerevents#353
Patrick: from my POV i think once i have answer regarding setting up `next` branch and merging stuff into it, then we can go ahead an merge that PR into it unless there's more work that needs to be done
Olli: are there tests for this?
<mustaq> web-platform-tests/
Mustaq: there are posts from wpt bot
Olli: does it check that the id is actually random? that's the critical part
Mustaq: those new tests are added to a new subfolder in pointer events, and that folder does not appear in WPT dashboard. should it?
<mustaq> https://
<mustaq> The folder appears there.
Mustaq: take it back, folder is there https://
Olli: so tests pass in all browsers? that doesn't make sense since it's not implemented
Mustaq: also PR had 3 files, but here i only see 2
Olli: ... it's a manual test
Mustaq: test checks for window.internals, and bails if not present...
Olli: is that chrome-only? or is it enabled only in testing? I think the tests need to be fixed somehow
Patrick: should we file issue in WPT repo?
Mustaq: we should comment on the PE pull request
Olli: i'll comment on it
Olli: other than this it should be fine
ACTION: wait to hear about fixed WPT. then we can decide to merge to next
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
Olli: think we're missing only one
Mustaq: I think Rob is planning to work on that one soon
Olli: I think one of the issues Masayuki filed needed a new test, or there was a bug in an existing one
<smaug> w3c/
Mustaq: I'll look into that
ACTION: continue work on remaining test, Mustaq to check the issue with test raised in 508
Touch Events - Quick update on the now-closed CG
Patrick: just quick heads-up to say that CG is now closed, and final version of the TE Level 2 note has been published as Final CG Specification. there have now belatedly been some mumblings about ACTUALLY making this an official spec, and that perhaps WebApps WG may want to inherit it, but will clarify this in person at TPAC
Patrick: meanwhile, thank you all as ever, and we'll reconvene in 2 weeks' time