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

Draft minutes: 2015 June 16 call

From: Arthur Barstow <art.barstow@gmail.com>
Date: Tue, 16 Jun 2015 12:19:27 -0400
Message-ID: <55804C8F.3010106@gmail.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Hi All,

The draft minutes for the June 16 PEWG call are available at the 
following and copied below:


If you have any comments, corrections, etc., please reply to this e-mail 
by June 23. 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

    16 Jun 2015


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


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


  * Topics <http://www.w3.org/2015/06/16-pointerevents-minutes.html#agenda>
     1. Tweak and agree on agenda
     2. Hover click with pointer events
     3. Non-scroll-blocking wheel events listeners / relationship to
     4. Expected behavior when releasing a button after pointer capture
     5. Capture semantics for a node that moves between documents
     6. Correcting inverted pan direction definition
     7. Bugs and Issues
     8. Implementation status
     9. AoB <http://www.w3.org/2015/06/16-pointerevents-minutes.html#item09>
  * Summary of Action Items


<scribe> ScribeNick: ArtB

<scribe> Scribe: ArtB

      Tweak and agree on agenda

AB:I posted a draft agenda 
includes quite a few topics but I think some of them might go quickly. 
Any change requests?

RB:can drop #5

… think we covered it on the list

AB:we can take it in order and then drop it

<rbyers> test now

      Hover click with pointer events

<rbyers> any better?

<scott_gonzalez> yes

<patrick_h_lauke> rbyers yes think so

AB:Timothy sent this e-mail to the list on April 
Patrick replied 
... if there is agreement to add this feature, then we need a PR or an 
Editor can take the lead and commit text.

<rbyers> crap

AB:Tim, Patrick, any comments?

PL:agree in principle would be good to have

TD:think we need some more text

<jrossi> had technical difficulties, but i'm here now

<jrossi> is the call working?

<jrossi> i'm on but don't hear anyone

RB:not clear how to update the spec for this

… think we need PRs and then discuss them

MA:think we need more text to cover this

<rbyers> Yes, let's discuss the specific spec impact

<patrick_h_lauke> i think there are two aspects to this from my point of 

AB:so I think Rick is asking for a proposal and/or PR. Is that correct Rick?

<rbyers> I think Mustaq was saying there are expections in the spec that 
may be violated by changing this

<patrick_h_lauke> a) do we open up the possibility that button/buttons 
is changed even when stylus is hovering

<patrick_h_lauke> (which it currently doesn't, at least on surface 3 + 
surface pen)

<patrick_h_lauke> b) whether we then also want to differentiate hovering 
pen vs touching pen

<patrick_h_lauke> +1 audio quality is...sub-par

<mustaq> I was trying to say: we have events for change-of-stylus-state 
w.r.t. touch surface...

AB:I think we need more discussion and proposals

<mustaq> but in this case we need events for button state changes.

<mustaq> like buttonchange?

<patrick_h_lauke> hmm, so that's perhaps even a third point

TD:I agree with following up on the list

<patrick_h_lauke> c) firing an event when button state changes

AB:ok, let's do that

      Non-scroll-blocking wheel events listeners / relationship to PEWG?

AB:Rick continued this thread on April 
there a specific Action and/or Issue(s) to record?

<scott_gonzalez> The spec says that you get a pointermove event if the 
buttons change.

<scott_gonzalez> "Additionally, when a pointer changes button state, 
pressure, tilt, or contact geometry (e.g. width and height) and the 
circumstances produce no other pointer events defined in this 
specification then a user agent must fire a pointer event named 

<patrick_h_lauke> scott ah, good point...forgot

RB:the big picture here is we are seeing cases where blocking event 
handlers are bad for perf

… have probs f.ex. wheel cases

… need to address wheel events and touch events

… not clear which group is the best place to have this discussion

… could be www-dom or public-touchevents

… I'll make a proposal on Github

… and then we can decide on how to proceed

AB:that sounds GTM

JR:I'm ok with having this discussion in this group

… and getting discussion on GH is good too

… this is definitely an area of interest to us v-a-v Edge

RB:we had some discussion with Moz/Toronto

… they have a heuristic that works for them

… it could be a counter-proposal to my wheel proposal

JR:or perhaps can do both

RB:I'll include information about why this is important to solve

AB:that SGTM

      Expected behavior when releasing a button after pointer capture

AB:Scott started this thread on April 
last reply seems to imply a change is 
it appears a concrete proposal (PR) would be useful.

[ Scott summarized the proposal ]

SG:Rick noted browsers are converging on this behavior for mouse events

RB:the history is complicated for mouse events

… not sure about the right answer

… we are doing some related compat testing

… can argue we need mouse and pe event compat

… We need implementation feedback to guide the design

SG:you mentioned FF is changing and Chrome is changing too

RB:both WK and Chrome do not fire events continuously during a scroll


SG:not sure if FF uses heuristic to prevent their behavior

RB:we need to be consistent with mouse events

… but we might want to also define the most rational thing for PE events 
(regardless of mouse events)

JR:think we need to be careful to change things just for one scenario 
(scrolling, animations, layout)

… haven't seen issues without having this behavior today

… I'm not particularly alamed by our behavior to change it

… but if I am missing some compat issues, then would be good to know

RB:mouse cursor is an interesting scenario

… we have a hack with a timer that updates mouse cursor

… what does IE do?

JR:not sure off the top-of-my-head

[ Jacob talks about IE implementation details ]

JR:if you have some impl feedback here, please share that info

<rbyers> Here's the main one:http://crbug.com/26723

AB:perhaps we should record an issue so we don't loose track of this


… would expect this to be tricky for us to implement

RB:there is definitely a potential performance hit

<rbyers> Relatedhttp://crbug.com/173712,http://crbug.com/246304,

JR:yes, agree there is a potential performance implication

<rbyers> Big picture issue that covers the whole space 

… therefore we need to know for sure there is a compelling compat issue 
that needs to be solved

SG:in general, yes I can see lots of changes might be needed

… but if just loosing pointer-capture, that's just one case

JR:I think the consequences could be broad for us

RB:think the changes for Chrome would be more incremental

… FF almost always updates the hover state

… IE only does the update if cursor moves

… and Chrome is somewhat in the middle

<scott_gonzalez> This is the oldest ticket I can find related to 

AB:would you Scott please create a GH Issue?


      Capture semantics for a node that moves between documents

AB:Rick started this thread on April 
cited text that appears to address Rick's question so not clear if this 
is a NOP or if some additional text would be helpful.

RB:I agree; let's move on

SG:lots of implementation diffs here

… f.ex. with replaceNode

RB:if there are related issues f.ex. in jQuery, please do let us know

      Correcting inverted pan direction definition

AB:on May 8 Rick committed a correction re the pan direction 

<jrossi> LGTM

AB:any other comments?

      Bugs and Issues

AB:there is one open Bugzilla 
bughttp://tinyurl.com/Bugs-PointerEventsand a few open 
... Do we want to discuss any of these today or expect discussion to 
continue online (i.e. the list, Bugzilla and/or Github)?



AB:so everyone, please provide feedback

      Implementation status

AB:any updates on implementation?

AV:Matt isn't here today re FireFox

<jrossi> new implementation: Microsoft Edge :-)

… so let's get that input next time

<jrossi> ;-)

DS:is the Edge mostly the same as IE impl?

JR:mostly the same; some bug fixes

<patrick_h_lauke> forgot where we stood with it, but: what are we doing 
about the event order / simplified model that Edge uses?

RB:we are actively landing patches

… Mustaq has patches

… still quite far from doing everything we need to do

JR:is there a flag yet?

RB:there is a flag in Canary

… have the basic support in JavaScript


RB:just a command line flag now

<rbyers> --enable-blink-features=PointerEvent

AV:which features are supported

RB:create and dispatch events now

… some p-up and p-down support

… no leave yet and other stuff missing

… can follow the status via a Chrome bug

<rbyers> Top level chrome bug:http://crbug.com/471824

AB:thanks for the updates


AB:any other topics for today

JR:there are some issues with test library

… need some new test cases

<rbyers> Firing pointer events for touch input is the main thing Mustaq 
is working on now.http://crbug.com/476565

… we plan to contribute them back and will ask for review

<mustaq> In canary, the --enable-blink-features=PointerEvent flag makes 
PEs visible.

<jrossi> yes it's pretty cool

SG:we pull in w3c test suite and pull them in with WebDriver


RB:want to talk about how to make the test more automated

DS:good; we need to do that across other groups too

SG:if there is a missing test, we will write it and automate it with WD

RB:are there some manual instructions too?

SG:we are loading the test as is and then feeds the assertion back

… and define WD steps in a separate file



RB:we need to do something like this too

… thus seems like we need to share these files

DS:yes, make them part of the harness

SG:agree; that's why I mentioned this topic

RB:definitely want to get more automation of w3c tests

DS:seems like we need to broaden the scope of the discussion

… since this isn't just PE specific

… I can set up a meeting

… Scott, is there a document about what you are doing?

SG:no; but we can create something

JR:agree this is important

… WebDriver needs more APIs then the basic features supported now

… especially for touch and pointer events

… think they need to do more work before we use WD directly for our 

RB:yes, we would be interested in a common way to do this

AB:so Doug, are you volunteering to start a thread or have a call


<jrossi> raises hand

… who is interested?





<asir> me too

… I think public-test-infra would be a place to start

… MikeSmith might know the WD driver list

<rbyers> WebDriver spec says public-browser-tools-testing@w3.org


<jrossi> sure, something predictable would be nice rather than ad hoc

AB:what about call frequency?

<rbyers> monthly sounds good to me

<rbyers> we can add more if necessary

AV:something predictable would be good and then cancel if necessary

<rbyers> sorry need to drop off

<mbrubeck> I'll just add on IRC that we enabled Pointer Events in 
Firefox Nightly a little while ago, found some bugs and disabled it, but 
should be ready to re-enable it in the next few days.

AB:Matt, that's great; thanks for this info!


AB:meeting adjourned

<asir> Thank you for sharing the info Matt! Great!

    Summary of Action Items

[End of minutes]
Received on Tuesday, 16 June 2015 16:19:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 June 2015 16:19:57 UTC