Draft minutes from 1 June 2016 call

Hi All,

draft minutes from the PEWG call on 1 June  are attached (since RRSAgent 
decided not to work, so no URL - had to manually generate these from IRC 
logs with scribe perl tool) and copied below as text.

If you have any comments, corrections, etc., please reply to this email 
by 7 June. In the absence of any changes, these minutes will be 
considered approved.



W3C

- DRAFT -

PEWG

02 Jun 2016

Attendees

Present
NavidZ, Mustaq_Ahmed, Rick_Byers, smaug, Dave_Tapuska, Dave_tapuska, 
teddink, Scott_Gonzalez, shepazu, mbrubeck
Regrets
Chair
patrick_h_lauke
Scribe
patrick_h_lauke
Contents

Topics
Should pointer IDs be unique even across different top-level browsing 
contexts?
Support hovering button states 
https://github.com/w3c/pointerevents/issues/14
Spec implies lost/gotpointercapture is delayed until the next pointer
Summary of Action Items
Summary of Resolutions
<scribe> scribe: patrick_h_lauke
Should pointer IDs be unique even across different top-level browsing 
contexts?

https://github.com/w3c/pointerevents/issues/59

Ted: sorry, dropped off my radar
... it's currently handled by a higher-level broker, so not directly in Edge

Rick: our concern is that it can't likely be implemented on all 
platforms if it's platform-specific
... so it's a potential interop issue. Question for ted: are there 
scenarios where this is crucial, like drag'n'drop across windows. is 
there anything that would break in Edge if ID was NOT consistent across 
windows

Ted: from D'n'D perspective i don't think so, because of how it's 
implemented under covers / interaction with OS and broker/container

broker handles all hand-offs of pointer and d'n'd integration

whether any developer is currently relying on it? doubt it, didn't have 
inter-window d'n'd until recently, so doubt there are web devs relying 
on this behavior

still worth for us (me) dig in a little more to verify what behavior 
we're seeing especially in cross-window scenario, if IDs are consistent 
or changing

Rick: we may want to put note in spec saying that they're NOT guaranteed 
to be consistent across windows

do we want to make IDs explicitly random so devs definitely don't think 
that there's consistency

thinking of scenarios where a framework may want to do this. open a 
popup window and communicate via postmessage, and they're sharing info / 
coordinating input. for ex. google feedback provides feedback on a 
google prop. uses iframes but could conceivable use popups

wondering if there are more scenarios like that where devs would expect 
IDs to be consistent

Ted: only way to be consistent would be if it was pressed DOWN 
consistently, as IDs can change

so would only work if people dragged between windows. also dragging into 
iframes, but we don't currently support it

Rick: so should we call this out in the spec, and note that Chrome/Edge 
have difference in implementation

RESOLUTION: add a note to spec - RICK

Support hovering button states 
https://github.com/w3c/pointerevents/issues/14

Navid: why not just use pointermove for all changes?

<smaug> you get pointerdown/up for button changes
<smaug> ?
Navid: the worry is if pointer turns into active button state

<smaug> click fires for left button only, but down/up for all
Navid: currently pointermove fires for all changes, but does the pointer 
turn active when hovering and buttons pressed?

Rick: for stylus, only active when touching digitizer

Mustaq: maybe we need to clarify - for hovering button press, you DON'T 
see a pointerdown; you see a pointermove with updated buttons; but 
pointer does NOT become active

Ted: it feels very consistent to me, echoing Rick's point keeping it 
simple and consistent

oops sorry...i'm terrible with voice recognition

<smaug> click is special
Rick: the problem is what happens when pressing buttons over an element 
while hovering. is it intentional manipulation?

developer who cares would write their own behavior

Oli (?): click is special though

has special behaviors / rules

Navid: [missed] make special case for primary?

Rick: Ted, hovering stylus with button clicks doesn't normally 
action/activate things?
... we may need to special case what it means for a stylus to be active

Ted: we should also keep in mind hovering touch scenarios

Mustaq: but it's different because you don't have a button that 
signifies an action/click in mid-air for touch

Ted: unless somebody implements some kind of gesture that is interpreted 
as a click
... pointermove indicates state change, but no pointerdown/pointerup 
until stylus touches screen

<dtapuska> mustaq: What about activation button state
(shepazu: rrsagent didn't join the channel despite being summoned with 
the right incantation)

Scott: but current spec doesn't allow for a change of buttons without a 
pointerdown (?)

Rick: spec is simpler if we don't add any further behavior (?)

<rbyers> Scott is arguing that the spec is simpler and easier to 
understand if we don't special-case stylus here. A hovering button press 
is just like a right-mouse-button press.
<rbyers> And less confusing to developers
<scott_gonzalez> Correct. And you can already detect a hovering click by 
looking at the buttons property.
Mustaq: we don't send click for any non-primary pointers, so change spec 
to also say not for hovering stylus

(sorry having hard time following conversation here)

Scott: we currently treat barrel press on hovering as nothing, only on 
contact

Rick: we could fix as scott suggests by fixing the chorded buttons section

Ted: so you could have the different states for barrel button, contact, 
and barrel + contact with different values

Rick: and Edge's behavior can still be per spec if hardware does not 
detect/support

Mustaq: button and buttons property has contact as condition...that's 
the problem

Rick: yes, if we go with Scott's proposal we remove that, it's simpler

is it real concern that users press barrel button by accident when hovering?

<dtapuska> some of this conversation relies on this proposal 
https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527 
(to fire only the click event on primary button)
Ted: let's write up the proposed solutions in github issue and i'll 
check with Jacob

Scott: only feedback found when looking for "hovering barrel button" was 
an issue of user complaining about autohiding task bar not appearing 
when hovering over bottom of screen...so seems low risk

as we're talking about NOT special casing hovering stylus, so this 
feedback supports it (treating it like a mouse)

as soon as device knows it's there it's treated like a mouse

Ted: suspicion is in windows if they swiped up from bezel, the taskbar 
would appear. windows likely treating it a bit like touch which has no hover

Scott: in touch we don't have buttons, so any activation is contact. but 
with stylus we can have button even without contact, so contact is not 
purely synonimous with activation

treat stylus tip like a button in its own right

<rbyers> Mustaq: what if both primary and barrel button are down when 
the pen contacts the screen?
<rbyers> Navid: would be as if the button changes happened outside the 
window - get pointerenter and no pointerdown
<rbyers> Scott: if you're hovering when you press the button you'd get 
pointerdown then
<rbyers> Mustaq: Yes, I Agree - was talking about devices that have no 
hover ability
<rbyers> Scott: would get pointerdown - property change caused buttons 
to go from 0 to non-zero
Scott: if barrel button is pressed for stylus that doesn't support hover 
in mid air and then you touch screen, you'd get pointerdown with the 
relevant button/buttons

<rbyers> Mustaq: we all agree on 'buttons' but what about 'button'?
<rbyers> Scott: expect it to be the primary pointer, it's the state 
change that causes the event to be fired
<rbyers> Mustaq: ok - current wording seems good enough
<rbyers> Dtapuska: what if you press barrel button, then contact 
digitizer, then lift off digitizer and make contact again
<rbyers> Scott: on recontact, buttons would be 1 if not holding barrel 
button, 3 if you were
(I think i have to make a demo to visualise button/buttons for my own 
sanity to then test with Surface 3/Stylus)

<rbyers> Navid: so can we add this proposal to the issue?
Ted: in general, no concerns with these points discussed so far, but 
will be good to see proposal

RESOLUTION: comment to be added to github issue for feedback

not PRing just yet

Spec implies lost/gotpointercapture is delayed until the next pointer

event but Edge does otherwise https://github.com/w3c/pointerevents/issues/32

Ted: spent most of day yesterday on issue, got few loose ends to tie up 
to check our implementation

today there's no delay

Mustaq: the problem comes when pointer ping/pongs between two elements

can end up crashing unless there's a delay. so we'd like to know if 
there's a heuristic at play

Ted: there may be some esotheric details, debouncing, working on it

RESOLUTION: Ted to find out more info

Summary of Action Items

Summary of Resolutions

add a note to spec - RICK
comment to be added to github issue for feedback
Ted to find out more info
[End of minutes]



-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke