Pointer Events Working Group Voice Conference -- 21 Apr 2015

<smaug> just a sec

<scribe> ScribeNick: ArtB

<scribe> Scribe: ArtB

Agree on Agenda

AB: yesterday I posted a draft agenda based on Rick's suggestions https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0062.html. Any change requests?

RB: we don't have to talk about all of these

… could take some to the list

AB: we can just go through them and move to list if needed

RB: sounds good

AB: I have a couple of items for AoB

Editing Policy and Change Control

AB: the group's "Editing Policy" is defined in https://www.w3.org/wiki/PointerEvents/WGCode#Editing_Policy and it states an "edit first, review later" workflow. The recent discussion thread is https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0053.html.
... there are two related Qs regarding PR review: 1) do Editors need approval before merging their PRs; 2) does an Editor need to review a PR from a non-Editor before it is merged. Currently, the Editors are Jacob and Matt.
... on the list I said the answer to these two Qs are No (which validates/confirms our Editing Policy) and Yes, respectively. Any disagreement with that?

… or other comments

RB: I forgot the Editing Policy

… don't think we need any changes

AB: any other comments?

[ None ]

RESOLUTION: PRs from Editors do not need to be reviewed before merging.
... PRs from non-Editors must be reviewed by an Editor before merging.

Normalize LF line endings

AB: this is about PR 5 https://github.com/w3c/pointerevents/pull/5. Is there a need to discuss or do we give the Editors an action to merge the PR?

JR: I'm happy to merge it

RB: I might have misunderstood something

… wasn't sure

<scribe> ACTION: Jacob to merge PR#5 [recorded in http://www.w3.org/2015/04/21-pointerevents-minutes.html#action01]

<trackbot> Created ACTION-150 - Merge pr#5 [on Jacob Rossi - due 2015-04-28].

<scott_gonzalez> ?w=1

JR: there is an option on GH

[ see Scott's info above ]

Value of a button in chorded events

AB: this is Issue #4 https://github.com/w3c/pointerevents/issues/4 which is the result of a comment on March 16 from Stuart Bentley https://lists.w3.org/Archives/Public/public-pointer-events/2015JanMar/0029.html.
... do we discuss now or take discussion to the Issue?

RB: I replied in the issue

… need input from JR

JR: because there is some inheritance from mouse, keeping with bitmap makes sense

… want to make it easier to write touch code

… We had briefly talked (perhaps on v2 wiki) if there is a new system f.ex. a new property to detect button state

<rbyers> In particular, interesting point Jacob mentioned that overlapping pointerdown/pointerup for the same pointer ID would be a pain for multi-touch

… f.ex. we thought about this for pens and erassers

… We could add some more information about button state

… but start to get into a lot of potential possibliities

… If we want to do something here, need to do something new

RB: agree but think the spec is a bit incomplete, perhaps not consistent

… says button follows from mouse event

… not specified how button should behave when multiple buttons are pressed

… Think the comment is that we need to be more explicit when multiple buttons are pressed

… We could eliminate the note [ref needed!]

JR: with button bitmask don't know specifically which button caused the event

… don't know which button just up'ed, for example

RB: need to define chord when there's a move

JR: oh, ok

… let me think how to address this

… I'll make a PR and send a link to it

<scribe> ACTION: submit a PR for issue #4 [recorded in http://www.w3.org/2015/04/21-pointerevents-minutes.html#action02]

<trackbot> Error finding 'submit'. You can review and register nicknames at <http://www.w3.org/2012/pointerevents/track/users>.

<scribe> ACTION: jacob submit a PR for issue #4 [recorded in http://www.w3.org/2015/04/21-pointerevents-minutes.html#action03]

<trackbot> Created ACTION-151 - Submit a pr for issue #4 [on Jacob Rossi - due 2015-04-28].

Discuss proposed spec text for direction-specific touch-action values

AB: this thread was started by Rick on March 17 https://lists.w3.org/Archives/Public/public-pointer-events/2015JanMar/0033.html and discussion has continued for a few weeks.
... on April 16, Rick's https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0048.html e-mail included a link to his proposal i.e. a spec diff https://github.com/RByers/w3c-pointerevents/compare/fix-crlf...RByers:touchaction-directions?diff=split&name=touchaction-directions

<rbyers> Left click then right click does: pointerdown button=0 buttons=1, pointermove button=2 buttons=3

AB: what do people think; have folks reviewed the proposal? Seems to me that Rick should submit a PR to w3c/pointerevents.

<rbyers> It's the value of 'button' on the pointermove that's currently unspecified (not inherited from the MouseEvents spec as the rest of button/buttons are).

RB: I haven't submitted a PR yet because I need the LF issue fixed first

AB: oh, ok

RB: would like to get feedback on the non-trivial issues

JR: read the spec text; seemed good to me

… but don't think we should do pan-* re the documentation

… think the more specificity would be better

RB: ok; I'll make that change

… not sure about the grammar

… I opted for the minimal grammar

… but I don't know if permissive or more restrictive is better

JR: need to be consistent

RB: should I be consistent with the spec or IE?

JR: with IE can do pan-x, pan-y, pinchzoom

… and I think the current spec does not permit that

… Think the PE spec needs to support this

… So pan-up and pan-down not possible with pan-y, right?

RB: correct

… shouldn't allow pan-down and pan-y because that is redundant

JR: I think what you have looks correct

RB: I think this is a simpler way to spec what we want

JR: looks good

RB: I combined another change re coordinate space

… added a sentence to state screen coords are being used

… is that OK?

JR: yes

… but last sentence doesn't look quite right

… I need to view the proposal v-a-v our gesture system

… if just have pan-right, can I undo the gesture i.e. pull it back to left?

RB: once scroll started, can go back even if moving in the reverse direction is not allowed

… need to be able to undo

RB: we can define what happens at and after the start

… can go back/reverse

… but can't change dimension

… tried to capture the various scenarios

JR: last sentence needs some work

RB: [ makes a proposal to update the text to address JR's concern ]

JR: would be good if we could proto this with JS

… want to make sure the edge cases still work

RB: think this is simple enough to impl to just go ahead and implement in Chrome

… but will do so behind a flag

… want to ship in Chrome 45

… but if we don't have sufficient data, can back off of that

AV: if you can give more data re shipping that would be helpful

RB: you mean PE in general or touch-action?

AV: Pointer Events

RB: I don't have any new info re schedule

AV: ok, please let us know when you have more data to share

RB: ok

JR: ok, so just want to make sure we do some experimenting before he make it part of the REC

<scott_gonzalez> We have use cases from all the native iOS apps (as of the time of the writing) for touch action here: http://www.w3.org/wiki/PointerEvents/TouchAction

RB: that sounds good
... there's also some text about nearest ancestor

… think that text isn't correct

JR: I'll need to look at the text

… oh, in the definition of pan-x

RB: [ reads defn of pan-x ]

… think the defn is not consistent with the proc model below

JR: so if have vert scroller and then horiz one above it?

RB: yes

JR: ok, I'll take a look at that v-a-v clarifying

… but your proposal looks ok (but need to check our impls)

RB: pull-to-refresh to work with PE requires t-a pan-down

… that behaviour (f.ex. twitter) a bit more common than carousel example

JR: we can have both examples

… need to make sure they both work

RB: ok, I'll update my PR and submit it

Non scroll blocking wheel-even listeners

AB: on April 16 Rick sent an "Non-scroll-blocking wheel events listeners / relationship to PEWG?" email https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0042.html and currently, there have been no replies.
... Rick asks "is there interest/feedback from this group, or discuss only on www-dom?" and he listed three options to address the issue.

RB: Olli replied today

OP: would need 4 params to event listener might work

RB: I'll reply on the list
... any feedback from you?

JR: agree there is a problem

… most cases wheel event uses default

… not much gesture recongnition there

RB: anecdotally, know of at least framework using wheel

[ Scribe notes some dialogue between JR and RB missing … ]

RB: touch-action works for PE because they are async

… in wheel case, events are typicall sync

… don't think a CSS property is sufficient

JR: need to think about this and continue discussion on the list

RB: I don't care much about wheel events scrolling perf

… but it is related to other probls that are high priority

… would be good if PointerEvents scenario is consistent with other events

JR: don't see this as a huge priority

… want to keep discussing this

RB: missing capability is how developers balance scroll performance and functionality

JR: somewhat related to track pad issues

AB: let's continue this discussion on the list

AoB

AB: Doug, what's the status of the PEWG extension to the end of 2015?

DS: it's in PLH's hands

<rbyers> smaug: Sorry I kind of brushed off your response - your audio was REALLY hard to follow. I think I got the gist and I agree we should continue discussion on the list.

DS: no need to worry
... re the errata, we talked about the location of the errata and we agreed with that location

<shepazu_> https://specs.webplatform.org/

<smaug> rbyers: nm. perhaps something to do with this hotel network. atm in Mountain View

JR: how do we want to handle errata for v1?

… do we patch the v1 spec?

… do we wipe the changes section in the v2 spec and then have the errata point to the v2 spec?

DS: I was addressing Art's Q about touch-events

JR: ok; that location is ok with me for PE errata

… I don't think a wiki for errata is a good idea

DS: agree

JR: do you want to help editing?

RB: sure

AB: congratulations to Rick, a new co-Editor for the Pointer Events spec

JR: for non-editorial changes, Editors can of course create a PR and let other Editors look at the PR before merging

RB: sounds good; I'd probably do that anyway

AB: all PRs should be auto-email'd to the list
... anything else for today?

[ Nothing ]

AB: meeting adjourned

- DRAFT -

Pointer Events Working Group Voice Conference

21 Apr 2015

Attendees

Contents