Draft minutes: 2016 May 11 call

Hi All,

draft minutes from the PEWG call on 11 May are available at

https://www.w3.org/2016/05/11-pointerevents-minutes.html

and copied below:

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

W3C
- DRAFT -

SV_MEETING_TITLE

11 May 2016

Agenda

See also: IRC log

Attendees

Present
Scott_Gonzalez, teddink, patrick_h_lauke, Matt_Brubeck
Regrets
Chair
SV_MEETING_CHAIR
Scribe
rbyers
Contents

Topics
Spec implies lost/gotpointercapture is delayed until the next pointer 
event but Edge does otherwise
outstanding minor github issues
next week meeting?
hackathon
Summary of Action Items
Summary of Resolutions
<scribe> ScribeNick: rbyers
<patrick_h_lauke> Main Issue: Should a captured pointer send transition 
events by default? https://github.com/w3c/pointerevents/issues/61
<NavidZ> https://github.com/w3c/pointerevents/issues/62
MA: I put this issue ahead of everything else because it affects everything

NZ: I added this issue for some of the details

<NavidZ> https://github.com/w3c/pointerevents/pull/63
NZ: Either the capturing element effectively shrinks to the capturing 
element borders
... Or the parent of the capturing element is expanded to the whole wall 
so you can never leave it
... This all goes away if we address the first issue - 61. Maybe we 
shouldn't send transition events at all?
... How bad would it be to not send transition events at all?

SG: I'm now on board with removing transition events during capture
... Wanted to hear from Edge team, eg. Jacob's button scenario
... why would they want implicit capture on buttons?

NZ: Didn't understand "implicit" capturing

SG: The only reason this was event discussed and put into the spec was 
because Edge was already doing implicit capturing on buttons
... but that scenario could work by checking bounding box co-ordinates
... key question is probably how it effects CSS hover

RB: I'd like to better understand the button scenario, I don't 
understand why capture is a good thing for buttons

TD: I agree with you, I don't understand either. Unfortunately Jacob is 
out so haven't been able to get details from him.
... discussions with development team, kept going back to today we're 
following the spec

SG: More accurate statement is the spec reflects what Edge does
... implementation already existed and we spec'd it
... behavior is contradictory to what the spec says because it does send 
events to elements which are not the captured element

TD: Don't disagree. But there are numerous places in the spec where we 
special case pointer capture

<patrick_h_lauke> RB: this is not fully spec'd. we made the spec match 
edge, but now we're hitting inconsistencies in practice
RB: I'd argue it's not really fully spec'd - there's a whole bunch of 
details that don't match behavior and we're having trouble "correcting" 
the spec because we don't understand Edge's precise behavior

NZ: Seems like we're violating the other specs around mouseenter/mouseleave

SG: Yeah but other spec also says that when you move your mouse you get 
mousemove events

NZ: An element may have the "hover" state (based on enter/leave) but 
parent doesn't, but that's inconsistent.

SG: If we want to support CSS hover during capture, no reason it 
couldn't work properly. But would be restricted to captured element and 
it's parents. Either hovering the captured element and all it's parents 
or nothing because you're only able to hit-test on one element

NZ: So then we'd send pointerenter to all the parents?

SG: No, what would you do with those events?

NZ: Trying to match CSS :hover with enter/leave events - tell the same story

MA: We define mouseenter/leave in relation to UI Event spec, so should 
get mouseenter for all the parents
... so maybe pointerenter should too?

SG: No, if you enter a tile that does not have a boundary inline with 
parent, then you won't get pointerenter on the parent

NZ: So how do we define hover states in capturing cases then?

SG: That's something we'd have to discuss
... either the hover state doesn't change during capture
... or hover is based only on the bounding box of the captured element

NZ: For first, hover the captured element or lock it?

SG: Could be either. The hovered element doesn't need to be the captured 
element.

NZ: In the design of no element having hover, then we need to send leave 
events to all elements

SG: Sure we could discuss if we send transition events prior to capture 
being applied
... could say we fire pointerleave up to the common ancestor before 
applying capture
... then nothing gets transition events

NZ: So the element is effectively always inside the common ancestor?

SG: Having a hard time thinking of scenarios where this would matter.

<smaug> (using the word "transition event" here is really misleading for 
anyone reading this stuff without knowing the context. Transition events 
are something defined in CSS-Transitions)
<patrick_h_lauke> RB: simplest - capture changes behavior of hit testing
RB: 3 consistency principles we're trying to uphold here:
... 1. CSS hover matches poitnerenter/pointerleave state
... 2. pointerenter/pointerleave state tell you what part of the tree 
will receive pointer events
... 3. during capture, only the captured element receives any pointer events
... Simplest model that does all this is the "capture modifies hit 
testing" concept, so on capture, captured element gets pointerenter and 
CSS hover and it doesn't change for the duration of capture

[scribe missed some discussion]

SG: Scenario developers are most excited about for capture is dragging.
... today you have to listen to mousedown on the element you care about, 
then you bind mousemove on the document
... so if you move too fast you don't loose the move events
... makes it much easier to deal with
... benefit of pointer capture is that you don't have to worry about 
where the pointer is in relation to the captured element
... another scenario: a spin button, as you drag off the button position 
changes to reflect the motion (even off the button)

PL: Right, same as slider scenario - usability/accessibility feature, 
don't require the user to keep their pointer precisely on the slider 
while dragging

<shepazu_> (note that this is called "hysteresis")
SG: finger/mouse goes off the thumb

MA: so how would you use transition events in this scenario?

SG: You wouldn't

SG .. just compare current pointermove X/Y co-ordinate to original 
co-ordinate on pointerdown

scribe: in the slider scenario you want to show the thumb as active 
regardless of where the pointer is
... either do care about CSS hover and want it to stay on that element, 
or you do it yourself via JS adding a class

PL: Another scenario: touch button, drag off to cancel and lift
... most native buttons behave this way
... button only activates if end position is over button
... only simple scenario I can think of where you would want hover

NZ: In that scenario, if you move your finger back in do you expect the 
button to activate?
... why would you capture in the first place?

PL: consider a user with dexterity problems, if slipped out accidentally 
should be able to slide back in and still activate
... to indicate that I'd want to show a visual hover state
... native button elements will do this for me
... but if I'm using a div etc. this becomes interesting

SG: Right, so then why use pointer capture at all in that button?

PL: To get the affordance

SG: Think about how you'd implement this - you'd listen to pointerdown, 
pointerup and care about "is the target within the button"
... can't detect that when doing capture without doing bounds checking
... so likely way to implement this is to not use pointer capture
... Edge and Firefox native buttons do this (Chrome doesn't) but they 
don't actually implement capture. Eg. can click on button, drag off onto 
an anchor and see hover state on anchor
... Don't actually implement a native capture-like behavior using mouse 
events today
... Only way to implement that button without bound checking is not to 
use pointer capture. Just use CSS hover and click events.
... This is what sparked the whole discussion about transition events 
during capture . Jacob brought up this button case, but after further 
investigation it seems those cases aren't really behaving like capture

NZ: Can't you implement all of this without mouse events? Just click and 
CSS styles?

SG: Yes, just click and CSS styles (click is conceptually a pointer event).

<patrick_h_lauke> probably related: 
http://codepen.io/patrickhlauke/pen/lBJhI so yes seems that you're right 
re click being fired even if i move off and back on even without 
pointercapture (just testing with a mouse anyway)
RB: I don't think we're going to be able to resolve this with more data, 
eg. on the compat impact.
... propose Chrome folks proceed with implementing without sending 
transition events during capture (since that's simplest) - the modified 
hit-testing approach
... then we can precisely compare Edge and Chrome behavior and look for 
the web compat impact

[scribe missed a bit]

<patrick_h_lauke> RB: hopefully Jacob can join us next week so we don't 
go ahead and miss his use case
NZ: So would we just leave all the issues open for now?

SG: Can we chat about what exactly would happen when capture is released?

MA: capture/release will behave as if the pointer moved to the element 
and then moved to current real position on release

SG: And do we do this immediately or on the next move?

NZ: That's separate, spec says wait until next event
... Edge sometimes does this but sometimes doesn't

RB: I think we can discuss that independently from this transition event 
issue

NZ: Ok we'll do that, what kind of data do we want to

<patrick_h_lauke> RB: let's do this as part/together with our implicit 
touch implementation, conceptually related to avoiding boundary checks 
on pointermove
<patrick_h_lauke> ... let's get this implemented and do testing
RB: Just lump this in with the compat testing work we're doing for 
implicit hit testing
... test top sites, look for differences in behavior

NZ: Ok seems like we've gotten through the first five

<NavidZ> https://github.com/w3c/pointerevents/issues/32
Spec implies lost/gotpointercapture is delayed until the next pointer 
event but Edge does otherwise

NZ: This is what Scott just referred to

TD: Unfortunately I didn't get a chance to dig into this yesterday

NZ: I'll summarize
... sepc says ("process pending pointer capture") invoked right before 
the next event that happens after setPointerCapture / releasePointerCapture
... so don't get lostpointercapture/gotpointercapture immediately after 
set/release calls
... but that's not what our tests are testing

<smaug> please file a bug about the crash
NZ: Edge seems to delay it sometimes, eg. if your gotpointercapture 
handler resets capture
... Firefox crashes in this scenario
... Not clear when Edge delays and when it doesn't
... Immediately doing it will be a problem, eg. stack overflow

MA: Or maybe the spec should be silent on the delay here?

NZ: Shouldn't matter as much
... but does in some scenarios. Eg. if page does setPointerCapture on 
pointerdown and user doesn't move the mouse
... In Edge you get gotpointercapture immediately, but Chrome you don't 
until the user moves

RB: To add some history, spec originally said the events were sent 
immediately
... And someone (Scott?) brought up the problem of stack overflow
... Jacob then added a bunch of complexity to the spec to try to capture 
the behavior
... But clearly Edge's behavior is more complex

TD: I'll get together with Jacob and the dev and form an opinion on this

RESOLUTION: TD to sync up with Jacob to review Edge's actual behavior 
compared to spec wording (and rationale behind why it does what it does)
RB: Edge's behavior seems like a good compromise to me here
... You do really want the events right away most of the time
... But in the edge cases (like changing capture during a 
gotpointercapture handler) you don't want to go crazy (stack overflow or 
infinite stream of events), so some heuristic / delay there makes sense.
... Probably should just understand Edge's behavior here and spec it.

PL: Do we need a resolution for the firs topic?

<patrick_h_lauke> shepazu ok we'll work out if we can skip one week's call
RESOLUTION: Chrome team to proceed with hit-test-override model of 
pointer capture and collect compat data

<patrick_h_lauke> RB: we're not going to ship until it's right (and 
until we can eliminate hit testing overhead), but this would be good for 
hackathon
OP: Are you saying Chrome would just ship this?

<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/4
RB: No, not talking about shipping until we have some consensus in this 
group
... just next steps in implementation and understanding compat impact

outstanding minor github issues

MA: I'll follow up on this one

next week meeting?

DS: I'm not necessary

PL: "Host has not arrived" message from WebEx
... Ok let's try to meet next week?

RB: I think it will depend if we can get Jacob's take on these big 
capture issues by next week

TD: I'm meeting with him on Monday.

hackathon

<patrick_h_lauke> RB: hackathon confirmed for tuesday/wednesday
TD: I'll let the list know whether or not we'll have data/context for a 
call by Monday afternoon

SG: Any update on hackathon?

TD: I'm arranging logistics

RB: One final thing, Chrome has pointer events behind a flag now. Some 
outstanding issues, but please play with it and give us your feedback

Summary of Action Items

Summary of Resolutions

TD to sync up with Jacob to review Edge's actual behavior compared to 
spec wording (and rationale behind why it does what it does)
Chrome team to proceed with hit-test-override model of pointer capture 
and collect compat data

-- 
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

Received on Wednesday, 11 May 2016 16:04:53 UTC