Re: Draft minutes: 2016 May 11 call

With Patrick out, let's skip and try following up on GitHub - see if we can
make progress on the outstanding items there and then discuss the outcome
on next week's call.

On Wed, May 18, 2016 at 10:08 AM, Ted Dinklocker <
Ted.Dinklocker@microsoft.com> wrote:

> Apologies for the late inquiry - are we having the call today? I was able
> to chat with Jacob and our development team yesterday and am better
> prepared to discuss both issues 61, 8, and 39. If we are not able to have
> the call today, then I will craft responses for the issues on GitHub so
> that we can continue the discussion electronically.
>
> -----Original Message-----
> From: Patrick H. Lauke [mailto:redux@splintered.co.uk]
> Sent: Wednesday, May 11, 2016 9:05 AM
> To: public-pointer-events@w3.org
> Subject: 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
>
>