W3C

- DRAFT -

Pointer Events Working Group Teleconference

04 May 2016

See also: IRC log

Attendees

Present
Rick_Byers, Matt_Brubeck, Dave_Tapuska, patrick_h_lauke, Scott_Gonzalez, Mustaq_Ahmed, shepazu, navid, teddink
Regrets
Chair
SV_MEETING_CHAIR
Scribe
dtapuska

Contents


<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

Adding scope of unique pointer id

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

Made mouseover/out/enter/leave event firing independent of corresponding PEs

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

https://github.com/w3c/pointerevents/pull/56

<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

Issue 39 Incorrect order of the events in process pending pointer capture section

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

Summary of Action Items

[NEW] ACTION: NZ to split that out into two issues [recorded in http://www.w3.org/2016/05/04-pointerevents-minutes.html#action01]
[NEW] ACTION: rbyers to fire new issue about transition events during capture [recorded in http://www.w3.org/2016/05/04-pointerevents-minutes.html#action02]
 

Summary of Resolutions

  1. items closed
  2. kill trackbot
  3. good, blocked on some minor editorial work from Patrick
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/04 16:10:45 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]