<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

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: rbyers
Inferring Scribes: rbyers
Present: Scott_Gonzalez teddink patrick_h_lauke Matt_Brubeck

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2016AprJun/0122.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 11 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/11-pointerevents-minutes.html
People with action items: