15:03:24 RRSAgent has joined #pointerevents 15:03:24 logging to http://www.w3.org/2016/05/11-pointerevents-irc 15:03:35 RRSAgent, this is Pointer Events 15:03:35 I'm logging. I don't understand 'this is Pointer Events', shepazu_. Try /msg RRSAgent help 15:03:45 present+ Scott_Gonzalez 15:04:08 teddink has joined #pointerevents 15:04:39 present+ teddink 15:04:45 RRSAgent, start 15:05:01 present+ teddink 15:05:09 ScribeNick: rbyers 15:05:12 present+ patrick_h_lauke 15:05:49 Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2016AprJun/0122.html 15:05:56 Main Issue: Should a captured pointer send transition events by default? https://github.com/w3c/pointerevents/issues/61 15:06:36 https://github.com/w3c/pointerevents/issues/62 15:06:44 MA: I put this issue ahead of everything else because it affects everything 15:07:01 NZ: I added this issue for some of the details 15:07:06 https://github.com/w3c/pointerevents/pull/63 15:07:27 .. Either the capturing element effectively shrinks to the capturing element borders 15:07:50 .. Or the parent of the capturing element is expanded to the whole wall so you can never leave it 15:08:09 .. This all goes away if we address the first issue - 61. Maybe we shouldn't send transition events at all? 15:08:17 .. How bad would it be to not send transition events at all? 15:08:31 SG: I'm now on board with removing transition events during capture 15:08:44 .. Wanted to hear from Edge team, eg. Jacob's button scenario 15:08:53 .. why would they want implicit capture on buttons? 15:09:15 NZ: Didn't understand "implicit" capturing 15:09:33 SG: The only reason this was event discussed and put into the spec was because Edge was already doing implicit capturing on buttons 15:09:47 .. but that scenario could work by checking bounding box co-ordinates 15:09:53 .. key question is probably how it effects CSS hover 15:10:21 RB: I'd like to better understand the button scenario, I don't understand why capture is a good thing for buttons 15:10:39 TD: I agree with you, I don't understand either. Unfortunately Jacob is out so haven't been able to get details from him. 15:11:09 .. discussions with development team, kept going back to today we're following the spec 15:11:49 SG: More accurate statement is the spec reflects what Edge does 15:11:57 .. implementation already existed and we spec'd it 15:12:21 .. behavior is contradictory to what the spec says because it does send events to elements which are not the captured element 15:12:48 TD: Don't disagree. But there are numerous places in the spec where we special case pointer capture 15:13:32 RB: this is not fully spec'd. we made the spec match edge, but now we're hitting inconsistencies in practice 15:13:40 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 15:14:07 NZ: Seems like we're violating the other specs around mouseenter/mouseleave 15:14:21 SG: Yeah but other spec also says that when you move your mouse you get mousemove events 15:15:00 NZ: An element may have the "hover" state (based on enter/leave) but parent doesn't, but that's inconsistent. 15:15:38 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 15:15:45 NZ: So then we'd send pointerenter to all the parents? 15:15:51 SG: No, what would you do with those events? 15:16:00 NZ: Trying to match CSS :hover with enter/leave events - tell the same story 15:16:43 MA: We define mouseenter/leave in relation to UI Event spec, so should get mouseenter for all the parents 15:16:47 .. so maybe pointerenter should too? 15:17:04 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 15:17:29 NZ: So how do we define hover states in capturing cases then? 15:17:36 SG: That's something we'd have to discuss 15:17:50 .. either the hover state doesn't change during capture 15:18:04 .. or hover is based only on the bounding box of the captured element 15:18:29 NZ: For first, hover the captured element or lock it? 15:18:38 SG: Could be either. The hovered element doesn't need to be the captured element. 15:18:59 NZ: In the design of no element having hover, then we need to send leave events to all elements 15:19:19 SG: Sure we could discuss if we send transition events prior to capture being applied 15:19:45 .. could say we fire pointerleave up to the common ancestor before applying capture 15:19:52 .. then nothing gets transition events 15:20:09 NZ: So the element is effectively always inside the common ancestor? 15:20:20 SG: Having a hard time thinking of scenarios where this would matter. 15:21:21 (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) 15:21:25 RB: simplest - capture changes behavior of hit testing 15:22:01 RB: 3 consistency principles we're trying to uphold here: 15:22:16 .. 1. CSS hover matches poitnerenter/pointerleave state 15:22:47 .. 2. pointerenter/pointerleave state tell you what part of the tree will receive pointer events 15:22:59 .. 3. during capture, only the captured element receives any pointer events 15:23:46 .. 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 15:24:07 [scribe missed some discussion] 15:24:28 SG: Scenario developers are most excited about for capture is dragging. 15:24:40 .. today you have to listen to mousedown on the element you care about, then you bind mousemove on the document 15:24:53 .. so if you move too fast you don't loose the move events 15:24:57 .. makes it much easier to deal with 15:25:12 .. benefit of pointer capture is that you don't have to worry about where the pointer is in relation to the captured element 15:25:54 .. another scenario: a spin button, as you drag off the button position changes to reflect the motion (even off the button) 15:26:14 PL: Right, same as slider scenario - usability/accessibility feature, don't require the user to keep their pointer precisely on the slider while dragging 15:26:15 (note that this is called "hysteresis") 15:26:23 present+ Matt_Brubeck 15:26:29 SG: finger/mouse goes off the thumb 15:26:37 MA: so how would you use transition events in this scenario? 15:26:40 SG: You wouldn't 15:27:09 SG .. just compare current pointermove X/Y co-ordinate to original co-ordinate on pointerdown 15:27:29 .. in the slider scenario you want to show the thumb as active regardless of where the pointer is 15:27:50 .. either do care about CSS hover and want it to stay on that element, or you do it yourself via JS adding a class 15:28:23 PL: Another scenario: touch button, drag off to cancel and lift 15:28:30 .. most native buttons behave this way 15:28:43 .. button only activates if end position is over button 15:29:10 .. only simple scenario I can think of where you would want hover 15:29:26 NZ: In that scenario, if you move your finger back in do you expect the button to activate? 15:29:36 .. why would you capture in the first place? 15:30:16 PL: consider a user with dexterity problems, if slipped out accidentally should be able to slide back in and still activate 15:30:47 .. to indicate that I'd want to show a visual hover state 15:31:02 .. native button elements will do this for me 15:31:12 .. but if I'm using a div etc. this becomes interesting 15:31:40 SG: Right, so then why use pointer capture at all in that button? 15:31:52 PL: To get the affordance 15:32:12 SG: Think about how you'd implement this - you'd listen to pointerdown, pointerup and care about "is the target within the button" 15:32:29 .. can't detect that when doing capture without doing bounds checking 15:32:43 .. so likely way to implement this is to not use pointer capture 15:33:10 .. 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 15:33:24 .. Don't actually implement a native capture-like behavior using mouse events today 15:33:46 .. Only way to implement that button without bound checking is not to use pointer capture. Just use CSS hover and click events. 15:35:03 SG: 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 15:35:30 NZ: Can't you implement all of this without mouse events? Just click and CSS styles? 15:35:43 SG: Yes, just click and CSS styles (click is conceptually a pointer event). 15:37:21 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) 15:37:47 RB: I don't think we're going to be able to resolve this with more data, eg. on the compat impact. 15:38:16 .. propose Chrome folks proceed with implementing without sending transition events during capture (since that's simplest) - the modified hit-testing approach 15:38:27 .. then we can precisely compare Edge and Chrome behavior and look for the web compat impact 15:38:39 [scribe missed a bit] 15:40:27 RB: hopefully Jacob can join us next week so we don't go ahead and miss his use case 15:40:38 NZ: So would we just leave all the issues open for now? 15:40:55 SG: Can we chat about what exactly would happen when capture is released? 15:41:19 MA: capture/release will behave as if the pointer moved to the element and then moved to current real position on release 15:41:28 SG: And do we do this immediately or on the next move? 15:41:37 NZ: That's separate, spec says wait until next event 15:41:44 .. Edge sometimes does this but sometimes doesn't 15:42:20 RB: I think we can discuss that independently from this transition event issue 15:42:33 NZ: Ok we'll do that, what kind of data do we want to 15:43:29 RB: let's do this as part/together with our implicit touch implementation, conceptually related to avoiding boundary checks on pointermove 15:43:44 ... let's get this implemented and do testing 15:43:46 RB: Just lump this in with the compat testing work we're doing for implicit hit testing 15:44:06 .. test top sites, look for differences in behavior 15:44:12 NZ: Ok seems like we've gotten through the first five 15:44:13 https://github.com/w3c/pointerevents/issues/32 15:44:27 Topic: Spec implies lost/gotpointercapture is delayed until the next pointer event but Edge does otherwise 15:44:39 NZ: This is what Scott just referred to 15:44:55 TD: Unfortunately I didn't get a chance to dig into this yesterday 15:44:57 NZ: I'll summarize 15:45:48 .. sepc says ("process pending pointer capture") invoked right before the next event that happens after setPointerCapture / releasePointerCapture 15:46:02 .. so don't get lostpointercapture/gotpointercapture immediately after set/release calls 15:46:06 .. but that's not what our tests are testing 15:46:26 please file a bug about the crash 15:46:27 .. Edge seems to delay it sometimes, eg. if your gotpointercapture handler resets capture 15:46:32 .. Firefox crashes in this scenario 15:47:00 .. Not clear when Edge delays and when it doesn't 15:47:11 .. Immediately doing it will be a problem, eg. stack overflow 15:47:23 MA: Or maybe the spec should be silent on the delay here? 15:47:29 NZ: Shouldn't matter as much 15:47:52 .. but does in some scenarios. Eg. if page does setPointerCapture on pointerdown and user doesn't move the mouse 15:48:07 .. In Edge you get gotpointercapture immediately, but Chrome you don't until the user moves 15:49:04 RB: To add some history, spec originally said the events were sent immediately 15:49:13 .. And someone (Scott?) brought up the problem of stack overflow 15:49:32 .. Jacob then added a bunch of complexity to the spec to try to capture the behavior 15:49:44 .. But clearly Edge's behavior is more complex 15:50:00 TD: I'll get together with Jacob and the dev and form an opinion on this 15:51:17 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) 15:51:22 RB: Edge's behavior seems like a good compromise to me here 15:51:35 .. You do really want the events right away most of the time 15:53:07 .. 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. 15:53:13 .. Probably should just understand Edge's behavior here and spec it. 15:53:23 PL: Do we need a resolution for the firs topic? 15:53:49 shepazu ok we'll work out if we can skip one week's call 15:53:52 RESOLUTION: Chrome team to proceed with hit-test-override model of pointer capture and collect compat data 15:54:52 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 15:55:16 OP: Are you saying Chrome would just ship this? 15:55:28 https://github.com/w3c/pointerevents/issues/4 15:55:34 RB: No, not talking about shipping until we have some consensus in this group 15:55:43 .. just next steps in implementation and understanding compat impact 15:55:47 Topic: outstanding minor github issues 15:56:27 MA: I'll follow up on this one 15:56:37 Topic: next week meeting? 15:56:52 DS: I'm not necessary 15:57:10 PL: "Host has not arrived" message from WebEx 15:57:57 PL: Ok let's try to meet next week? 15:58:17 RB: I think it will depend if we can get Jacob's take on these big capture issues by next week 15:58:24 TD: I'm meeting with him on Monday. 15:59:22 topic: hackathon 15:59:23 RB: hackathon confirmed for tuesday/wednesday 15:59:31 .. I'll let the list know whether or not we'll have data/context for a call by Monday afternoon 15:59:39 SG: Any update on hackathon? 15:59:52 TD: I'm arranging logistics 16:00:34 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 16:01:04 rrsagent, make minutes 16:01:04 I have made the request to generate http://www.w3.org/2016/05/11-pointerevents-minutes.html patrick_h_lauke 16:01:21 rrsagent, set logs world-visible 16:02:03 rrsagent, stop