See also: IRC log
<patrick_h_lauke> anybody brave enough to scribe?
<patrick_h_lauke> ok no worries
I can try to scribe again
<patrick_h_lauke> dtapuska i'll take you up on the offer if that's ok. your minutes from last time were spot on i thought
<patrick_h_lauke> scribe: dtapuska
<patrick_h_lauke> * old actions hanging around in Track https://www.w3.org/2012/pointerevents/track/actions/open - can we close them?
<patrick_h_lauke> * open issues/pull requests
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues
<patrick_h_lauke> https://github.com/w3c/pointerevents/pulls
<patrick_h_lauke> Specifically:
<patrick_h_lauke> 1. Pull-requests for issues discussed in the last meeting:
<patrick_h_lauke> - Adding the scope of unique pointerId:
<patrick_h_lauke> https://github.com/w3c/pointerevents/pull/57
<patrick_h_lauke> - Made mouseover/out/enter/leave event firing independent of corresponding PEs
<patrick_h_lauke> https://github.com/w3c/pointerevents/pull/56
<patrick_h_lauke> 2. Issue: Incorrect order of the events in process pending pointer capture section
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/39
<patrick_h_lauke> Proposed fix: Reorder the events in process pending pointer capture
<patrick_h_lauke> https://github.com/w3c/pointerevents/pull/40
<patrick_h_lauke> 3. Related issue: Determine when boundary events are fired after capture is released
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/15
<patrick_h_lauke> 4. Spec implies lost/gotpointercapture is delayed until next PE but Edge does otherwise
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/32
<patrick_h_lauke> * steps for FPWD publication (mainly for Patrick's benefit, for Doug to answer)
<patrick_h_lauke> - rewriting intro/abstract to explain difference to PE REC
<patrick_h_lauke> - examples of FPWD intent to publish + CfC (2 weeks) emails? where are those sent?
PL: Thanks for shifting meeting; here are the proposed agenda items
<patrick_h_lauke> https://www.w3.org/2012/pointerevents/track/actions/open
PL: Two old remaining issues in
track
... teddink can you look at them; whether they can be closed?
So we don't have any loose ends
RB: Issue 4 is still open; but we don't need both a tracker and github
PL: Lets close issue 4
RB: The other one is sending
usage data to list
... Don't think this is too important
TD: I've got it but I havent' sent it. Clearly haven't sent it to the list
RB: Ya we got some stuff privately
TD: Will double check with jacob to double check we can send it to the list
RESOLUTION: items closed
RB: Let's call this issue as closed then (Action 154)
PL: mustaq proposed we tackle the 4 issues in github
<patrick_h_lauke> Adding the scope of unique pointerId:
<patrick_h_lauke> (4:06:47 PM) patrick_h_lauke: https://github.com/w3c/pointerevents/pull/57
RB: We agreed last week should be according to the top level browsing context
TD: Will that be normative?
RB: Yes; I think so. We will write a test for this. It is ripe for interop issues.
NZ: Only for touch though; since mouse only has one pointer id
RB: Some issues with drag and drop; +teddink was going to provide some information how Edge handles drag and drop
<patrick_h_lauke> Issue: Incorrect order of the events in process pending pointer capture section
<patrick_h_lauke> (4:06:47 PM) patrick_h_lauke: https://github.com/w3c/pointerevents/issues/39
<trackbot> Created ISSUE-1 - Incorrect order of the events in process pending pointer capture section. Please complete additional details at <http://www.w3.org/2012/pointerevents/track/issues/1/edit>.
PL: So we are happy with that; so it's closed; already merged
RB: Can we get rid of trackbot since we aren't using it
DF: Ya you can just boot trackbot
RESOLUTION: kill trackbot
DF: It's tied into RSS agent but I think we can get rid of it separately
<patrick_h_lauke> once we know how
RB: mustaq made a pull request for this
<patrick_h_lauke> related pull request: https://github.com/w3c/pointerevents/pull/40
RB: have been iterating a bit on
it. I think we should merge the request. But follow up with
tests. We know edge has a bug here but it isn't clear what the
issue is
... We haven't reached agreement yet on what the spec should be
here
NZ: Perhaps we can look at the issue with a sequence of events
<rbyers> https://github.com/w3c/pointerevents/issues/35
<patrick_h_lauke> apologies, got confused with pulls
mustaq: Since there can be multiple primary pointers that legacy mouse code can see inconsistent legacy events
MA: So we broke the 1:1 mapping of PE to legacy events
RB: Paste change:
<rbyers> Key section proposing a change: https://rawgit.com/mustaqahmed/pointerevents/gh-pages/index.html#tracking-the-effective-position-of-the-legacy-mouse-pointer
RB: In particular the wording
here redirects the legacy events is according to the UIEvents
spec
... there is one virtual legacy mouse pointer.
... As close to Edge's current behaviour but it is definitely
different
TD: Fundamentally we agree with
this approach; have a dev that wants to do some debugging for
us to determine that it is relatively easy for us to
implement
... The dev wanted to debug what was going on under the covers;
he didn't have time to do it last night. This is fundamentally
tied to another change we wanted isn't it?
NZ: There is an issue with the
capturing case
... What happens when we have a capture and release it
MA: But they are separate enough right? This one is just about how legacy mouse events are received.
RB: I agree they are orthogonal. This is our only issue with the legacy mouse events
TD: Issue 35 is tied with pull
request 56
... And we agree with the ordering that Navid was proposed on
March 4th
... We are going to do some debugging to be 100% sure. And that
edge is a little off here.
PL: The language is a little sloppy but we are saying it is normative
RB: I think this section is optional; but if you implement this section is should be a MUST
PL: How do we make this section optional but have a MUST inside it?
RB: The reason why we made this section optional so some futuristic world that you wouldn't need to generate legacy events. But if you do generate them then you MUST follow this.
MA: Section 11 says it is optional
RB: User agents are encouraged to generate legacy events; but if you don't care you can avoid generating legacy events.
PL: Can we may it explicit. Perhaps just a bit of editorial work.
RB: We can say this pull request is blocked on some editorial work from PL.
MA: 11.2 and 11.3 use MAY
... Should check the MAY vs SHOULD language
RESOLUTION: good, blocked on some minor editorial work from Patrick
RB: Those don't necessarily bother me; but let's follow up on the pull request
<patrick_h_lauke> Incorrect order of the events in process pending pointer capture section
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/39
Topic; https://github.com/w3c/pointerevents/issues/39
NZ: So there are two problems 1)
When we have the transition of capture; ie resetting it to
something else
... Right now the spec doesn't have get and lost correct
... First element has the capture, and the second got it
... When an element has the capture, the blue has the capture;
but the green is getting the events
RB: This violates the spec where when an item has the capture than another element doesn't get events
NZ: Don't think we added all the
if/elses to capture all the cases
... perhaps I'm just matching what I've written in chrome;
doesn't feel that we are capturing them all
MA: Scotts' filed issue https://github.com/w3c/pointerevents/issues/15
RB: The behaviour that NZ highlighted in issue 39 do we agree that is a bug?
SG: Yes
TD: Yes; agree as well
PL: Agree
RB: Should they occur between 17 and 18?
NZ: Both of them are valid.
RB: Right different sequences can occur; don't think spec should say with is valid
NZ: We are forcing the order
here. Try to avoid saying pointer enter/leave completely
... But if we have 4 paragraphs we need to order them
RB: If we have an algorithm then it is precise
NZ: I can add all the if/elses
and update an old pull request and see what others think about
it
... If a pointer is capture we don't send any pointer
transition events
SG: It would be simplified; but
things would have to be queried. When mouse is down
... and you had a mouse down; you wouldn't get the updated
hover state if you don't fire the transition events
<rbyers> Kinda all tied up in this big issue: https://github.com/w3c/pointerevents/issues/8
NZ: Part of that issue 8 tied up
in 39
... What does it do about it's parents. When an item gets a
capture; over and out == on the element
... vs enter/leave
MA: Is it all the nodes or is it inclusive?
NZ: When you leave an element you send it to all the parents.
RB: Ya you are just talking about when you have an element that has capture; and you move the mouse to another element does that count as a leave
NZ: Depends on if it is children or not.
MA: What about something that is hovering on top; does it all go out?
RB: We've tried to have hover
effect match mouse enter/leave
... I'd assume we want that in this case too
... We'd want the pointer leave when you moved off and the
button to loose the hover style as well
SG: Have an old behaviour of when
a hover effect after a scroll
... Do you get hover instantly or on the next mouse move. Do we
wait for another movement effect to take anything.
RB: This has been a long standing issue. Edge is only based on physical mouse movement
<scott_gonzalez> The long standing issue with hover timing behavior: http://dev-test.nemikor.com/behavior/mouseover-when-element-is-shown.html
RB: We've tried in chrome so the developer has a consistent state. This is a huge issue; let's try to get back to the issue. Come back to our hit testing performance at a later day
NZ: Do we consider the children of the element in terms of the transition
SG: out and over is same as mouse enter/leave.
NZ: Doesn't mean that you children are overlapping
RB: Edge is already doing one thing; is there a reason that edge is doing something wrong
NZ: No there isn't
RB: Let's improve the spec to define what edge is doing.
<scott_gonzalez> https://www.w3.org/TR/pointerevents/#h3_setting-pointer-capture
RB: We are changing the semantics of hit testing not over and out
SG: There is a note here; let's just expand that note.
RB: Similar to how we defined enter and leave we do here
NZ: That doesn't solve the original issue of the ordering
<scribe> ACTION: NZ to split that out into two issues [recorded in http://www.w3.org/2016/05/04-pointerevents-minutes.html#action01]
MA: Can we make some type of assumption?
RB: Have a section to define how
hit testing works; want pointer move events targeted at the
capture node. But we also want transition events
... When you are in the capture phase the transition events
have different semantics
... Ideally once you are capturing it changes the semantics of
hit testing
SG: Perhaps it wouldn't be that
difficult to do hit testing your self; cause you'd need to do
that for drag and drop
... If you want hover behaviour on a button and you could do
boundary testing. But if you are relying on css hover then you
can have an issue
RB: Don't people set the dragging node to pointer events none and rely on the browser doing the hit testing
SG: Two things during a drag you
want to capture. Today we listen to mouse down on the element
but mouse move on the document
... but you want to use capture to avoid that. But you do want
to hit testing because you want to hit test on the size of the
dragable item. Not pointer hit testing
RB: Ya you want intersection
testing not pointer testing
... If we stick with the current behaviour isn't a constant
stream of pointer over/out.. Is that how Edge behaves
today?
TD: We'd need to do some
testing.
... The move events just have large deltas.
RB: You could be dragging from the middle and moving at a velocity of half of the width of the draggable every frame
SG: Ya but that is pretty fast movement.
RB: Ya that is probably rare. Some day we have to document hit testing. And all of this is defining behaviour of an algorithm that isn't specified
<shepazu> (I once started the spec for hit testing… CSS needs this too)
SG: Do we care about CSS hover during capture?
<patrick_h_lauke> is it worth taking this/working with other WG, like whoever is doing UI Events ?
SG: Its only when you hover when the draggabl
RB: In these drag and drop cases the pseudo hover style is potentially changing. It should be a no-op if the UI is implemented well
SG: In the jquery UI case we only care about the draggable; but in the gmail case when you are moving the message into a tab I don't know if it is relying on css hover
RB: You don't want to update the
hover state and don't generate enter/leave
... But this isn't what edge has shipped
NZ: Do we have any metrics of determining when someone is using capture and wants transition events
RB: Almost out of time. Sounds like should be an issue about what should transition events do during capture
<scribe> ACTION: rbyers to fire new issue about transition events during capture [recorded in http://www.w3.org/2016/05/04-pointerevents-minutes.html#action02]
PL: Is any other working group working on specifying hit testing? Like UIEvents?
<patrick_h_lauke> sorry doug i jumped in there
RB: There are other groups; tabatkins tried to do it in CSS WG
DF: I agree we should have co-ordination but not blocking
RB: I think we should write some great tests. Shouldn't be afraid of testing behaviour of testing hit testing even though algorithm isn't specified
SG: What happens on release
capture. Edge doesn't do that until you actually generate
another move
... styling differences for buttons.
RB: Out of time for today
<patrick_h_lauke> for next meeting, review Spec implies lost/gotpointercapture is delayed until next PE but Edge does otherwise - https://github.com/w3c/pointerevents/issues/32
PL: Follow up with Doug on the
draft version will catch up with him on the mailing list
... Same time next week
patrick_h_lauke: Can you take care of terminating rss agent?
<patrick_h_lauke> yup will do (sorry had to dash afk for a sec)
<patrick_h_lauke> and thanks again for superb minute taking
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) Succeeded: s/ordering that mustaq/ordering that Navid/ Succeeded: s/SC/SG/ Found Scribe: dtapuska Inferring ScribeNick: dtapuska Present: Rick_Byers Matt_Brubeck Dave_Tapuska patrick_h_lauke Scott_Gonzalez Mustaq_Ahmed shepazu navid teddink WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/04-pointerevents-minutes.html People with action items: nz rbyers[End of scribe.perl diagnostic output]