15:02:12 <RRSAgent> RRSAgent has joined #pointerevents
15:02:12 <RRSAgent> logging to http://www.w3.org/2016/05/04-pointerevents-irc
15:02:14 <trackbot> RRSAgent, make logs 231
15:02:16 <trackbot> Zakim, this will be 7394
15:02:17 <trackbot> Meeting: Pointer Events Working Group Teleconference
15:02:17 <trackbot> Date: 04 May 2016
15:02:17 <Zakim> ok, trackbot
15:02:27 <rbyers> present+ Rick_Byers
15:02:32 <mbrubeck> present+ Matt_Brubeck
15:02:34 <dtapuska> present +Dave_Tapuska
15:02:39 <patrick_h_lauke> present+ patrick_h_lauke
15:02:51 <scott_gonzalez> present+ Scott_Gonzalez
15:03:09 <patrick_h_lauke> anybody brave enough to scribe?
15:03:27 <patrick_h_lauke> ok no worries
15:03:44 <dtapuska> I can try to scribe again
15:04:14 <mustaq> present+ Mustaq_Ahmed
15:04:30 <circ-user-akbUE> circ-user-akbUE has joined #pointerevents
15:04:31 <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
15:04:39 <patrick_h_lauke> scribe: dtapuska
15:04:52 <shepazu> present+ shepazu
15:05:43 <navid> present+ navid
15:06:02 <teddink> teddink has joined #pointerevents
15:06:18 <teddink> present+ teddink
15:06:47 <patrick_h_lauke> * old actions hanging around in Track  https://www.w3.org/2012/pointerevents/track/actions/open - can we close  them?
15:06:47 <patrick_h_lauke> * open issues/pull requests
15:06:47 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues
15:06:47 <patrick_h_lauke> https://github.com/w3c/pointerevents/pulls
15:06:48 <patrick_h_lauke> Specifically:
15:06:48 <patrick_h_lauke> 1. Pull-requests for issues discussed in the last meeting:
15:06:48 <patrick_h_lauke>   - Adding the scope of unique pointerId:
15:06:49 <patrick_h_lauke>     https://github.com/w3c/pointerevents/pull/57
15:06:49 <patrick_h_lauke>   - Made mouseover/out/enter/leave event firing independent of  corresponding PEs
15:06:49 <patrick_h_lauke>     https://github.com/w3c/pointerevents/pull/56
15:06:50 <patrick_h_lauke> 2. Issue: Incorrect order of the events in process pending pointer  capture section
15:06:50 <patrick_h_lauke>     https://github.com/w3c/pointerevents/issues/39
15:06:50 <patrick_h_lauke>     Proposed fix: Reorder the events in process pending pointer capture
15:06:51 <patrick_h_lauke>     https://github.com/w3c/pointerevents/pull/40
15:06:51 <patrick_h_lauke> 3. Related issue: Determine when boundary events are fired after capture  is released
15:06:51 <patrick_h_lauke>     https://github.com/w3c/pointerevents/issues/15
15:06:52 <patrick_h_lauke> 4. Spec implies lost/gotpointercapture is delayed until next PE but Edge  does otherwise
15:06:52 <patrick_h_lauke>     https://github.com/w3c/pointerevents/issues/32
15:06:52 <patrick_h_lauke> * steps for FPWD publication (mainly for Patrick's benefit, for Doug to  answer)
15:06:52 <patrick_h_lauke>   - rewriting intro/abstract to explain difference to PE REC
15:06:52 <patrick_h_lauke>   - examples of FPWD intent to publish + CfC (2 weeks) emails? where  are those sent?
15:07:06 <dtapuska> PL: Thanks for shifting meeting; here are the proposed agenda items
15:07:19 <patrick_h_lauke> https://www.w3.org/2012/pointerevents/track/actions/open
15:07:27 <dtapuska> PL: Two old remaining issues in track
15:07:57 <dtapuska> PL: teddink can you look at them; whether they can be closed? So we don't have any loose ends
15:08:18 <dtapuska> RB: Issue 4 is still open; but we don't need both a tracker and github
15:08:23 <dtapuska> PL: Lets close issue 4
15:09:02 <dtapuska> RB: The other one is sending usage data to list
15:09:17 <dtapuska> RB: Don't think this is too important
15:09:30 <dtapuska> TD: I've got it but I havent' sent it. Clearly haven't sent it to the list
15:09:37 <dtapuska> RB: Ya we got some stuff privately
15:10:03 <dtapuska> TD: Will double check with jacob to double check we can send it to the list
15:10:13 <patrick_h_lauke> RESOLUTION: items closed
15:10:26 <dtapuska> RB: Let's call this issue as closed then (Action 154)
15:10:50 <dtapuska> PL: mustaq proposed we tackle the 4 issues in github
15:10:50 <patrick_h_lauke> Adding the scope of unique pointerId:
15:10:51 <patrick_h_lauke> (4:06:47 PM) patrick_h_lauke:     https://github.com/w3c/pointerevents/pull/57
15:11:02 <dtapuska> Topic: Adding scope of unique pointer id
15:11:31 <dtapuska> RB: We agreed last week should be according to the top level browsing context
15:11:37 <dtapuska> TD: Will that be normative?
15:12:03 <dtapuska> RB: Yes; I think so. We will write a test for this. It is ripe for interop issues.
15:12:20 <dtapuska> NZ: Only for touch though; since mouse only has one pointer id
15:12:44 <dtapuska> RB: Some issues with drag and drop; +teddink was going to provide some information how Edge handles drag and drop
15:12:55 <patrick_h_lauke> Issue: Incorrect order of the events in process pending pointer  capture section
15:12:55 <patrick_h_lauke> (4:06:47 PM) patrick_h_lauke:     https://github.com/w3c/pointerevents/issues/39
15:12:55 <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>.
15:12:58 <dtapuska> PL: So we are happy with that; so it's closed; already merged
15:13:43 <dtapuska> RB: Can we get rid of trackbot since we aren't using it
15:14:00 <dtapuska> DF: Ya you can just boot trackbot
15:14:19 <patrick_h_lauke> RESOLUTION: kill trackbot
15:14:23 <dtapuska> DF: It's tied into RSS agent but I think we can get rid of it separately
15:14:24 <patrick_h_lauke> once we know how
15:14:46 <dtapuska> Topic: Made mouseover/out/enter/leave event firing independent of  corresponding PEs
15:15:01 <dtapuska> RB: mustaq made a pull request for this
15:15:28 <patrick_h_lauke> related pull request: https://github.com/w3c/pointerevents/pull/40
15:15:38 <dtapuska> ... 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
15:15:51 <dtapuska> ... We haven't reached agreement yet on what the spec should be here
15:16:08 <dtapuska> NZ: Perhaps we can look at the issue with a sequence of events
15:16:44 <rbyers> Topic: https://github.com/w3c/pointerevents/pull/56
15:17:15 <rbyers> https://github.com/w3c/pointerevents/issues/35
15:17:17 <patrick_h_lauke> apologies, got confused with pulls
15:17:41 <dtapuska> mustaq: Since there can be multiple primary pointers that legacy mouse code can see inconsistent legacy events
15:18:08 <dtapuska> MA: So we broke the 1:1 mapping of PE to legacy events
15:18:15 <dtapuska> RB: Paste change:
15:18:19 <rbyers> Key section proposing a change: https://rawgit.com/mustaqahmed/pointerevents/gh-pages/index.html#tracking-the-effective-position-of-the-legacy-mouse-pointer
15:18:49 <dtapuska> RB: In particular the wording here redirects the legacy events is according to the UIEvents spec
15:19:05 <dtapuska> ... there is one virtual legacy mouse pointer.
15:19:25 <dtapuska> ... As close to Edge's current behaviour but it is definitely different
15:20:06 <dtapuska> 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
15:20:40 <dtapuska> TD: 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?
15:20:52 <dtapuska> NZ: There is an issue with the capturing case
15:21:04 <dtapuska> NZ: What happens when we have a capture and release it
15:21:25 <dtapuska> MA: But they are separate enough right? This one is just about how legacy mouse events are received.
15:21:43 <dtapuska> RB: I agree they are orthogonal. This is our only issue with the legacy mouse events
15:21:53 <dtapuska> TD: Issue 35 is tied with pull request 56
15:22:13 <dtapuska> TD: And we agree with the ordering that mustaq was proposed on March 4th
15:22:38 <dtapuska> TD: We are going to do some debugging to be 100% sure. And that edge is a little off here.
15:22:56 <trackbot> trackbot has left #pointerevents
15:23:02 <dtapuska> PL: The language is a little sloppy but we are saying it is normative
15:23:21 <rbyers> s/ordering that mustaq/ordering that Navid/
15:23:21 <dtapuska> RB: I think this section is optional; but if you implement this section is should be a MUST
15:23:48 <dtapuska> PL: How do we make this section optional but have a MUST inside it?
15:24:31 <dtapuska> 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.
15:24:38 <dtapuska> MA: Section 11 says it is optional
15:25:04 <dtapuska> RB: User agents are encouraged to generate legacy events; but if you don't care you can avoid generating legacy events.
15:25:24 <dtapuska> PL: Can we may it explicit. Perhaps just a bit of editorial work.
15:25:40 <dtapuska> RB: We can say this pull request is blocked on some editorial work from PL.
15:25:58 <dtapuska> MA: 11.2 and 11.3 use MAY
15:26:16 <dtapuska> MA: Should check the MAY vs SHOULD language
15:26:44 <patrick_h_lauke> RESOLUTION: good, blocked on some minor editorial work from Patrick
15:26:46 <dtapuska> RB: Those don't necessarily bother me; but let's follow up on the pull request
15:27:06 <patrick_h_lauke> Incorrect order of the events in process pending pointer  capture section
15:27:06 <patrick_h_lauke>     https://github.com/w3c/pointerevents/issues/39
15:27:07 <dtapuska> Topic; https://github.com/w3c/pointerevents/issues/39
15:27:16 <rbyers> Topic: Issue 39 Incorrect order of the events in process pending pointer capture section
15:27:58 <dtapuska> NZ: So there are two problems  1) When we have the transition of capture; ie resetting it to something else
15:28:12 <dtapuska> ... Right now the spec doesn't have get and lost correct
15:28:28 <dtapuska> ... First element has the capture, and the second got it
15:29:02 <dtapuska> ... When an element has the capture, the blue has the capture; but the green is getting the events
15:29:20 <dtapuska> RB: This violates the spec where when an item has the capture than another element doesn't get events
15:29:50 <dtapuska> NZ: Don't think we added all the if/elses to capture all the cases
15:30:14 <dtapuska> ... perhaps I'm just matching what I've written in chrome; doesn't feel that we are capturing them all
15:30:41 <dtapuska> MA: Scotts' filed issue https://github.com/w3c/pointerevents/issues/15
15:31:13 <dtapuska> RB: The behaviour that NZ highlighted in issue 39 do we agree that is a bug?
15:31:19 <dtapuska> SG: Yes
15:31:28 <dtapuska> TD: Yes; agree as well
15:31:31 <dtapuska> PL: Agree
15:31:49 <dtapuska> RB: Should they occur between 17 and 18?
15:32:12 <dtapuska> NZ: Both of them are valid.
15:32:29 <dtapuska> RB: Right different sequences can occur; don't think spec should say with is valid
15:32:50 <dtapuska> NZ: We are forcing the order here. Try to avoid saying pointer enter/leave completely
15:33:13 <dtapuska> NZ: But if we have 4 paragraphs we need to order them
15:33:23 <dtapuska> RB: If we have an algorithm then it is precise
15:33:58 <dtapuska> NZ: I can add all the if/elses and  update an old pull request and see what others think about it
15:34:44 <dtapuska> NZ: If a pointer is capture we don't send any pointer transition events
15:35:24 <dtapuska> SG: It would be simplified; but things would have to be queried. When mouse is down
15:35:55 <dtapuska> SG: and you had a mouse down; you wouldn't get the updated hover state if you don't fire the transition events
15:35:59 <rbyers> Kinda all tied up in this big issue: https://github.com/w3c/pointerevents/issues/8
15:36:22 <dtapuska> NZ: Part of that issue 8 tied up in 39
15:37:07 <dtapuska> NZ: What does it do about it's parents. When an item gets a capture; over and out == on the element
15:37:39 <dtapuska> NZ: vs enter/leave
15:37:52 <dtapuska> MA: Is it all the nodes or is it inclusive?
15:38:22 <dtapuska> NZ: When you leave an element you send it to all the parents.
15:38:47 <dtapuska> 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
15:39:03 <dtapuska> NZ: Depends on if it is children or not.
15:39:37 <dtapuska> MA: What about something that is hovering on top; does it all go out?
15:39:55 <dtapuska> RB: We've tried to have hover effect match mouse enter/leave
15:40:06 <dtapuska> ... I'd assume we want that in this case too
15:40:24 <dtapuska> ... We'd want the pointer leave when you moved off and the button to loose the hover style as well
15:40:47 <dtapuska> SG: Have an old behaviour of when a hover effect after a scroll
15:41:13 <dtapuska> SG: Do you get hover instantly or on the next mouse move. Do we wait for another movement effect to take anything.
15:41:36 <dtapuska> RB: This has been a long standing issue. Edge is only based on physical mouse movement
15:42:01 <scott_gonzalez> The long standing issue with hover timing behavior: http://dev-test.nemikor.com/behavior/mouseover-when-element-is-shown.html
15:42:29 <dtapuska> ... 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
15:42:44 <dtapuska> NZ: Do we consider the children of the element in terms of the transition
15:43:12 <dtapuska> SC: out and over is same as mouse enter/leave.
15:43:19 <dtapuska> s/SC/SG
15:43:56 <dtapuska> NZ: Doesn't mean that you children are overlapping
15:44:19 <dtapuska> RB: Edge is already doing one thing; is there a reason that edge is doing something wrong
15:44:27 <dtapuska> NZ: No there isn't
15:44:46 <dtapuska> RB: Let's improve the spec to define what edge is doing.
15:44:51 <scott_gonzalez> https://www.w3.org/TR/pointerevents/#h3_setting-pointer-capture
15:44:59 <dtapuska> RB: We are changing the semantics of hit testing not over and out
15:45:12 <dtapuska> SG: There is a note here; let's just expand that note.
15:45:28 <dtapuska> RB: Similar to how we defined enter and leave we do here
15:45:47 <dtapuska> NZ: That doesn't solve the original issue of the ordering
15:46:06 <dtapuska> ACTION: NZ to split that out into two issues
15:47:06 <dtapuska> MA: Can we make some type of assumption?
15:47:50 <dtapuska> 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
15:48:06 <dtapuska> RB: When you are in the capture phase the transition events have different semantics
15:48:21 <dtapuska> ... Ideally once you are capturing it changes the semantics of hit testing
15:49:02 <dtapuska> 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
15:49:38 <dtapuska> SG: 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
15:50:08 <dtapuska> RB: Don't people set the dragging node to pointer events none and rely on the browser doing the hit testing
15:50:40 <dtapuska> 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
15:51:35 <dtapuska> ... 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
15:51:53 <dtapuska> RB: Ya you want intersection testing not pointer testing
15:53:02 <dtapuska> ... If we stick with the current behaviour isn't a constant stream of pointer over/out.. Is that how Edge behaves today?
15:53:16 <dtapuska> TD: We'd need to do some testing.
15:53:46 <dtapuska> TD: The move events just have large deltas.
15:54:31 <dtapuska> RB: You could be dragging from the middle and moving at a velocity of half of the width of the draggable every frame
15:54:45 <dtapuska> SG: Ya but that is pretty fast movement.
15:55:15 <dtapuska> 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
15:55:20 <shepazu> (I once started the spec for hit testing… CSS needs this too)
15:55:38 <dtapuska> SG: Do we care about CSS hover during capture?
15:56:03 <patrick_h_lauke> is it worth taking this/working with other WG, like whoever is doing UI Events ?
15:56:30 <dtapuska> SG: Its only when you hover when the draggabl
15:57:09 <dtapuska> 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
15:57:49 <dtapuska> 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
15:58:13 <dtapuska> RB: You don't want to update the hover state and don't generate enter/leave
15:58:27 <dtapuska> ... But this isn't what edge has shipped
15:58:55 <dtapuska> NZ: Do we have any metrics of determining when someone is using capture and wants transition events
15:59:24 <dtapuska> RB: Almost out of time. Sounds like should be an issue about what should transition events do during capture
15:59:47 <dtapuska> ACTION: rbyers to fire new issue about transition events during capture
15:59:59 <shepazu> q+
16:00:22 <dtapuska> PL: Is any other working group working on specifying hit testing? Like UIEvents?
16:00:26 <patrick_h_lauke> sorry doug i jumped in there
16:00:44 <dtapuska> RB: There are other groups; tabatkins tried to do it in CSS WG
16:00:45 <shepazu> q-
16:01:07 <dtapuska> DF: I agree we should have co-ordination but not blocking
16:01:47 <dtapuska> 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
16:02:49 <dtapuska> SG: What happens on release capture. Edge doesn't do that until you actually generate another move
16:03:19 <dtapuska> ... styling differences for buttons.
16:03:48 <dtapuska> RB: Out of time for today
16:03:49 <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
16:04:33 <dtapuska> PL: Follow up with Doug on the draft version will catch up with him on the mailing list
16:04:37 <dtapuska> PL: Same time next week
16:09:03 <dtapuska> patrick_h_lauke: Can you take care of terminating rss agent?
16:10:03 <patrick_h_lauke> yup will do (sorry had to dash afk for a sec)
16:10:12 <patrick_h_lauke> and thanks again for superb minute taking
16:10:40 <patrick_h_lauke> rrsagent, generate minutes
16:10:40 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/04-pointerevents-minutes.html patrick_h_lauke
16:10:52 <patrick_h_lauke> trackbot, bye
16:10:56 <patrick_h_lauke> hmmm...
16:11:52 <patrick_h_lauke> rrsagent, bye
16:12:13 <patrick_h_lauke> rrsagent, make logs world-visible
16:12:19 <patrick_h_lauke> rrsagent, bye
16:12:19 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2016/05/04-pointerevents-actions.rdf :
16:12:19 <RRSAgent> ACTION: NZ to split that out into two issues [1]
16:12:19 <RRSAgent>   recorded in http://www.w3.org/2016/05/04-pointerevents-irc#T15-46-06
16:12:19 <RRSAgent> ACTION: rbyers to fire new issue about transition events during capture [2]
16:12:19 <RRSAgent>   recorded in http://www.w3.org/2016/05/04-pointerevents-irc#T15-59-47