- From: Arthur Barstow <art.barstow@gmail.com>
- Date: Tue, 16 Jun 2015 12:19:27 -0400
- 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:
<http://www.w3.org/2015/06/16-pointerevents-minutes.html>
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
Agenda
<https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0111.html>
See also:IRC log <http://www.w3.org/2015/06/16-pointerevents-irc>
Attendees
Present
Art_Barstow, Scott_González, Rick_Byers, Patrick_H_Lauke,
Tim_Dresser, Mustaq_Ahmed, Asir_Vedamuthu, Jacob_Rossi,
Doug_Schepers, Matt_Brubeck
Regrets
Chair
ArtB
Scribe
ArtB
Contents
* Topics <http://www.w3.org/2015/06/16-pointerevents-minutes.html#agenda>
1. Tweak and agree on agenda
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item01>
2. Hover click with pointer events
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item02>
3. Non-scroll-blocking wheel events listeners / relationship to
PEWG?
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item03>
4. Expected behavior when releasing a button after pointer capture
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item04>
5. Capture semantics for a node that moves between documents
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item05>
6. Correcting inverted pan direction definition
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item06>
7. Bugs and Issues
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item07>
8. Implementation status
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#item08>
9. AoB <http://www.w3.org/2015/06/16-pointerevents-minutes.html#item09>
* Summary of Action Items
<http://www.w3.org/2015/06/16-pointerevents-minutes.html#ActionSummary>
------------------------------------------------------------------------
<scribe> ScribeNick: ArtB
<scribe> Scribe: ArtB
Tweak and agree on agenda
AB:I posted a draft agenda
yesterdayhttps://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0111.html.It
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
22https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0080.htmland
Patrick replied
yesterdayhttps://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0112.htmlvoicing
support.
... 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
view
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
22https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0081.html.Is
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
pointermove."
<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
27https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0089.html.Rick's
last reply seems to imply a change is
neededhttps://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0092.htmli.e.
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
<scott_gonzalez>http://dev-test.nemikor.com/behavior/mouseover-when-element-is-shown.html
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
JR:sure
… 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
here:http://crbug.com/488886
… 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
this:https://bugzilla.mozilla.org/show_bug.cgi?id=20022
AB:would you Scott please create a GH Issue?
SG:yes
Capture semantics for a node that moves between documents
AB:Rick started this thread on April
30https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0095.html.Scott
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
definitionhttps://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0100.html(commithttps://github.com/w3c/pointerevents/commit/8548506a7db4de67fa6b8ca997887fdb6a0c8056).
<https://github.com/w3c/pointerevents/commit/8548506a7db4de67fa6b8ca997887fdb6a0c8056%29.>Any
comments?
<jrossi> LGTM
AB:any other comments?
Bugs and Issues
AB:there is one open Bugzilla
bughttp://tinyurl.com/Bugs-PointerEventsand a few open
Issueshttps://github.com/w3c/pointerevents/issues.
... Do we want to discuss any of these today or expect discussion to
continue online (i.e. the list, Bugzilla and/or Github)?
JR:no
RB:no
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
AB:great
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
AoB
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
<jrossi>https://github.com/jquery/pep
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
<scott_gonzalez>https://github.com/jquery/PEP/blob/master/tests/functional/pointerevent_button_attribute_mouse-manual.js
<jrossi>https://github.com/theintern/recorder
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
scenarios
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
DS:yes
<jrossi> raises hand
… who is interested?
RB:me
SG:me
JR:me
AB:me
<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
<rbyers>https://w3c.github.io/webdriver/webdriver-spec.html
<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!
<scott_gonzalez>https://github.com/jquery/PEP/blob/master/tests/intern.js#L6-L10
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