Meeting minutes
[quick round of introductions for the benefit of Olga and Adam, new WG members joining us from Microsoft]
Limit the precision of floating point event fields w3c/pointerevents#517
Rob: meant to write something up, but as mentioned in previous meeting: location should be at least pixel level; and we need to be careful about potential banding if we artificially limited precision that would then lead to jumps (e.g. pressure)
ACTION: continue iterating, Rob to write up a few thoughts on the issue
Ensure predicted events only use input from the current partition w3c/pointerevents#518
Patrick: i promised that i'd monkey-patch this to at least make it clear what we mean by "past" (i.e. the preceding points of the current gesture/interaction, not "when the user last visited this a few days ago"). suggest i'll do this for next meeting, then we have something to expand further
Rob: also limit it specifically to "current webpage" or similar, be very specific, to make it clear devs won't have more access to things than they should
ACTION: Patrick to make first pass PR to clarify
[PointerEvent algorithms] Order of boundary events w3c/pointerevents#519
mustaq: UI events spec wants to become more algorithmic, and that showed up a few discrepancies with our own handling. this was before TPAC. but at TPAC it was decided that UI events will handle mouse events (?)
<mustaq> https://
https://
mustaq: there are four of these algorithm issues altogether. they're more longer-term. not for Level 3
Olli: agree this is more for Level 4, Next ... post Level 3
Rob: we have clear direction, we just need to make sure it's all handled consistently
Adam: is it that mouse events currently are getting turned into pointer events, for enter/leave...
mustaq: not a problem of event per se, but which spec specifies the behavior
Rob: developers won't see any difference. it's just which order, which timing, events are being fired
[touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516
Adam: in short, we need a way to separate handwriting from scrolling behavior
Adam: e.g. an app adds a toggle to explicitly switch between handwriting and regular pointing device for their stylus
Adam: one proposal was to do this as an attribute in HTML. another idea was to piggy-back on touch-action as a new value to differentiate between handwriting and panning
Adam: no way currently to allow granular control
<mustaq> w3c/
Rob: the way we built stylus on android is that handwriting is equivalent to scrolling (?)
Rob: not sure if 203 is same issue. when you put stylus down, you CAN pan, you CAN write, nothing for author to stop one or the other
Adam: you can only limit pan to one direction, but not completely suppress pan AND allow handwriting
Rob: pan and manipulation might disable handwriting
Rob: problem is that touch action is applied as a bitmask down the tree ... if the parent limits to just panning, for instance, it would then disable handwriting further down
Olga: so we won't be able to enable handwriting on a child if parent has limited to just pan
Rob: if we don't include handwriting as a concept as part of pan
Olga: as Adam pointed out, this might be more a problem for older pages, but not for new ones
Adam: yes, new ones may already take that into account. so adding a new value for handwriting to touch-action sounds like the way to go
Rob: might be worth also thinking about other actions like text selection
Adam: should it be included in the manipulation set?
mustaq: in Chrome manipulation is pan and zoom
Rob: i think it should probably be in manipulation
Rob: we should have some other property to determine whether you want ... how you want to treat these devices, but maybe touch-action is sufficient. in other issue (512) i talk about how we might want to allow mice to pan. that's more a "how to treat this device"
Olga: in future it could allow handwriting with mouse (in ref to 512)
mustaq: in reference to 203, that was a wider idea of moving away from touch-action to a few more specific properties
Olli: is there a situation where you'd also want different pointers/styli to behave differently?
Adam: some styluses support things like a toggle/switch to trigger different behaviors, stylus with eraser. not sure what that would look like
Olga: to be clear, we just want to allow author to specify that they want to allow handwriting with a pointer (stylus, finger) rather than interpreting it as a pan (?)
mustaq: what to do when a device doesn't support handwriting? should it fall back to then allowing pan?
mustaq: what i imagine is a page with lots of inputs, and you want to allow an author to say "for touch, just pan; for pen, make it do handwriting"
Adam: would be good to allow both, but have handwriting take precedence. Would be useful to allow defining different behaviors for different pointer types too
<mustaq> w3c/
mustaq: there's no consensus there, but the issue there mentions this idea of making it more granular / per pointer type
<mustaq> pointer-action: touch(pan-y), pen(none);
ACTION: iterate further on the issue w3c/
Coalesced and predicted event attributes within an untrusted event w3c/pointerevents#514
mustaq: my concern was that authors may trust the trusted bit too much, even though the list comes from an untrusted event...
ACTION: mustaq to propose a PR with clarification, Olli to review
Ambiguity of the value of the button property for the click event w3c/pointerevents#513
Olli: ...in this case click needs to follow UI events
mustaq: the special case i proposed will be breaking...
Olli: we can't change behaviour, just need to clarify it
ACTION: Patrick to attempt first PR to clarify/document this
Triage unlabelled issues https://github.com/w3c/pointerevents/issues
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
mustaq: think we only have one left at this point. Rob landed it, but it was reverted.
ACTION: Rob to review his WPT (and why it might have been reverted)