W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2015

Draft minutes: 2015 April 21 call

From: Arthur Barstow <art.barstow@gmail.com>
Date: Tue, 21 Apr 2015 12:10:49 -0400
Message-ID: <55367689.1090808@gmail.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Hi All,

The draft minutes for the April 21 PEWG call are available at the 
following and copied below:


If you have any comments, corrections, etc., please reply to this e-mail 
by April 28. In the absence of any changes, these minutes will be 
considered approved.

-Thanks, AB

W3C <http://www.w3.org/>

  - DRAFT -

  Pointer Events Working Group Voice Conference

    21 Apr 2015


See also:IRC log <http://www.w3.org/2015/04/21-pointerevents-irc>


    Art_Barstow, Asir_Vedamuthu, Scott_González, Jacob_Rossi,
    Olli_Pettay, Rick_Byers, Tim_Dresser, Doug_Schepers, Matt_Brubeck
    Sangwhan_Moon, Patrick_H_Lauke


  * Topics <http://www.w3.org/2015/04/21-pointerevents-minutes.html#agenda>
     1. Agree on Agenda
     2. Editing Policy and Change Control
     3. Normalize LF line endings
     4. Value of a button in chorded events
     5. Discuss proposed spec text for direction-specific touch-action
     6. Non scroll blocking wheel-even listeners
     7. AoB <http://www.w3.org/2015/04/21-pointerevents-minutes.html#item07>
  * Summary of Action Items


<smaug> just a sec

<scribe> ScribeNick: ArtB

<scribe> Scribe: ArtB

      Agree on Agenda

AB:yesterday I posted a draft agenda based on Rick's 
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 
inhttps://www.w3.org/wiki/PointerEvents/WGCode#Editing_Policyand it 
states an "edit first, review later" workflow. The recent discussion 
... 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 5https://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 

<trackbot> Created ACTION-150 - Merge pr#5 [on Jacob Rossi - due 

<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 #4https://github.com/w3c/pointerevents/issues/4which is 
the result of a comment on March 16 from Stuart 
... 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 

<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 

<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 
discussion has continued for a few weeks.
... on April 16, 
included a link to his proposal i.e. a spec 

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


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


… 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 

… 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


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 

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?


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

JR:somewhat related to track pad issues

AB:let's continue this discussion on the list


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


<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


JR:do you want to help editing?


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

    Summary of Action Items

*[NEW]**ACTION:*jacob submit a PR for issue #4 [recorded 
*[NEW]**ACTION:*Jacob to merge PR#5 [recorded 
*[NEW]**ACTION:*submit a PR for issue #4 [recorded 

[End of minutes]
Received on Tuesday, 21 April 2015 16:11:18 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 16 May 2015 00:31:59 UTC