- 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