Meeting minutes
Limit the precision of floating point event fields w3c/pointerevents#517
Olli: I added a comment
Rob: I was on the hook to write something up. I have strong feelings that precision should be at least down to device pixel level, and not to create excessive banding
Rob: to bring back to root concern, even choosing higher precision of the two options, it's not going to be precise enough to reveal things like battery fluctuations
ACTION: Rob to draft an initial basic PR to get some of these thoughts down for us to iterate over
Ensure predicted events only use input from the current partition w3c/pointerevents#518
Patrick: I was the one that I'd do an initial basic PR for discussion, but had no time since last meeting. Promise that for the next meeting I'll have something to discuss
ACTION: Patrick to draft a PR to address this
[touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516
Patrick: I think one of the concerns we've had in the discussion of the issue since the meeting was what should happen on devices that don't support handwriting, and developers not being aware that effectively this will result in touch-action: none unintentionally
Rob: trying to think how we tackled this with things like zoom ... just to make sure that users can also still pan
Rob: if an authors specifies pinch-zoom, does that mean they can't pan? that's the same footgun
Mustaq: this is the same potential problem
<mustaq> Pinch-zoom in a separate bit in Chromium: https://
<mustaq> Here is the spec: https://
Patrick: I admit that I am still not quite understanding the use case of touch-action: handwriting, as from the presentation at BlinkOn (?) it seems that this uses heuristics by default - if i start handwriting near an input/writeable field, it assumes i'm handwriting. so this touch-action: handwriting seems the opposite of what you'd want...telling the browser NOT to do handwriting
Rob: this is consistent though with other touch actions
Patrick: but it means that up to now, if a dev had set any specific touch-action, and they omitted handwriting (as it didn't exist), the browser should IGNORE handwriting, but it clearly isn't at the moment
Rob: except if we say that manipulation includes handwriting
ACTION: further discussion on the issue, as some aspects (use case in particular) aren't quite clear to all
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
Patrick: think we were close, only had this one for now w3c/
Rob: I put together a test page for this
Rob: as at first I thought Chrome was allowing bidirectional (?) capture, but testing this with the new test page i couldn't repro. so might be WPT framework has some bug/issue that gives wrong result
Olli: ... we'll still need the same origin test though
[discussion on how out-of-process might affect test/check]
<flackr> https://
Rob: both of the captures in the above demo fail
Mustaq: you're seeing same behaviour, regardless of which direction you go
Rob: i also think the silent failure may not be right. we loudly fail in other cases, why be silent on this one
Rob: would anybody be opposed to allowing same origin capture? or should we delay until we see people needing it?
Rob: if goal is to specify what's implemented, we can just test the current thing and figure out why the WPT behaves differently from this test page...
Olli: thinking of other cases other than same origin...
Rob: don't feel strongly we need to enable this - currently not allowed, and not heard any feedback from devs complaining about this, to my knowledge
Patrick: suggest perhaps opening a new future speculative issue "should this be relaxed?", and passing this to a few other folks (including those from Apple) and see what the feedback there is, but for right now for v3 just investigate WPT oddity
ACTION: Rob et al, investigate WPT odd behaviour for this test
ACTION: Open speculative new issue about potential relaxing of the requirement for same origin
Patrick: Rob is it worth also filing a new issue/doing a PR about not silently failing, but loudly failing?
Olli: so about throwing error?
Rob: yeah we throw in other similar scenarios, but in this case we silently fail
Rob: in my mind, the developer contract is much clearer if you request a capture and it throws if it wasn't possible/allowed
Mustaq: this would be fine with me
Olli: not sure we can just push it for v3
Rob: we're masking developer bugs
Patrick: we can leave it for now in v3, and earmark it for a consistency update in v4/future
ACTION: File an issue about future update to make failed capture throw
Triage unlabelled issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+-label%3Av3++-label%3Av3-blocking
Mustaq: suggest we devote time next meeting to just go through them right there in the call
Thank you all