Draft minutes: 2016 May 4 call

Hi All, (to shamelessly channel ArtB)

draft minutes from the PEWG call on 4 May are available at

https://www.w3.org/2016/05/04-pointerevents-minutes.html

and copied below. If you have any comments, corrections, etc., please 
reply to this email by 3 May. In the absence of any changes, these 
minutes will be considered approved.


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

Topics
Adding scope of unique pointer id
Made mouseover/out/enter/leave event firing independent of corresponding PEs
https://github.com/w3c/pointerevents/pull/56
Issue 39 Incorrect order of the events in process pending pointer 
capture section
Summary of Action Items
Summary of Resolutions
<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

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

-- 
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

Received on Wednesday, 4 May 2016 16:46:10 UTC