See also: IRC log
<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
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
MA: I'll follow up on this one
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.
<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:[End of scribe.perl diagnostic output]