- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 21 Mar 2018 16:07:22 +0000
- To: public-pointer-events@w3.org
Minutes from today's call: Pointer Events WG 21 Mar 2018 Attendees Present: NavidZ, Olli_Pettay, Patrick_H_Lauke, Mustaq Chair: Patrick H. Lauke Scribe: Patrick H. Lauke <NavidZ_> https://github.com/w3c/pointerevents/issues?page=1&q=is%3Aissue+is%3Aopen+-label%3Afuture-v3&utf8=%E2%9C%93 <NavidZ_> https://rawgit.com/smaug----/test-results/d2b1bcc451c5b85d2b1d0cb721a2f732b3c01120/pointerevents/less-than-2.html Above link is what Google care most about in Olli's test/PR Olli: apparently some tests were missed. Framework for (manual) tests is broken/times out <NavidZ_> https://github.com/w3c/pointerevents/issues/229 Patrick: we'll go through issues #229 future-v3 <NavidZ_> https://github.com/w3c/pointerevents/issues/226 #226 assigned to Navid. we discussed last week, let user agents handle it <NavidZ_> https://github.com/w3c/pointerevents/issues/225 #225 same - discussed last week, added test for that yesterday <NavidZ_> https://github.com/w3c/pointerevents/issues/221 #221 discussed last meeting, asssigned to Patrick <NavidZ_> https://github.com/w3c/pointerevents/issues/220 #220 we're just going to follow terminology for pointer lock <NavidZ_> https://github.com/w3c/pointerevents/issues/219 #219 assigned to Olli <NavidZ_> https://github.com/w3c/pointerevents/issues/202 #202 new one, not discussed yet. assigned to Patrick atm. this comes from direct manipulation inputs that scroll. do we want different pen actions, or do touch actions also apply to pen actions? chrome currently: if the direct manipulation device is capable of scrolling (see input capabilities), it listens to touch-action Navid: Olli will firefox do something here do you know? Olli: no input currently on this one Mustaq: we may defer to v3, as we haven't got consensus yet Patrick/Olli agree <NavidZ_> https://github.com/w3c/pointerevents/issues/183 #183 assigned to patrick <NavidZ_> https://github.com/w3c/pointerevents/issues/177 #177 Olli: there's a test for this, but Firefox is failing. we have some inconsistency which events are logged and which are not (w3c tests) <smaug> https://searchfox.org/mozilla-central/source/dom/html/nsGenericHTMLElement.cpp#2222 Navid: should we define this in PE? Patrick: would prefer having it in upstream (e.g. UI Events?) Olli: Chrome was going to change this earlier this year - mouse events Navid: should we fire events then on disabled? Olli: certainly not click, chrome currently fires pointerup and pointerdown Navid: in latest stable, chrome sends all pointer events, but no mouse events <NavidZ_> https://www.chromestatus.com/features/5685077795143680 Navid i'll add this to myself, look for the test, expect pointerup/down/move on disabled events, but no click Patrick: should this be mentioned in the PE spec, or is it already implied/mentioned in other upstream specs? <NavidZ_> https://github.com/w3c/web-platform-tests/blob/master/pointerevents/pointerevent_disabled_form_control-manual.html Olli: it should be said explicitly *somewhere* maybe just a note somewhere about disabled elements navid: i'll add a note as well to spec <NavidZ_> https://github.com/w3c/pointerevents/issues/173 #173 question: when we release pointer capture, should boundary events be fired/update hover etc when capture is release, in chrome at least, it waits until NEXT event to then fire all the events to get out of the previous (captured) element and into the new element the pointer is now over chrome does currently for concrete events. olli do you know how firefox behaves? olli: don't recall right now. thinking what right way to do it would be <smaug> I lost audio navid/mustaq discuss interaction between scrolling by keyboard and boundary events (as page and mouse move against each other) (smaug shout if you get back in) navid/mustaq discuss pointercapture - that after getpointercapture chrome also waits until next concrete event (setpointercapture) boundary events are equivalent to hovering - after pointer leaves, page cannot find out which element is currently hovered until next concrete event? Olli: yeah agree that makes no sense. hover is always updated Navid: so you agree we SHOULD fire boundary events right away after pointer capture is released? Olli: yes, that would be what developers expect I think Navid: chrome currentyl waits for next concrete event, but sending right away makes more sense Olli: i think Firefox sends mouseover when page scrolls using keyboard, but not mousemove ... would be good to test current behavior Navid: Olli can you take care of testing? Olli agrees Patrick: and add a note in spec clarifying this <NavidZ_> https://github.com/w3c/pointerevents/issues/172 #172 dupe of https://github.com/w3c/pointerevents/issues/219? https://github.com/w3c/pointerevents/issues/171 #171 navid: i believe dblclick itself is kind of legacy, as click received the detail/click count navid: seems outside of scope of pointer events. and that the issue itself is a mess. but we never talked about it in PE. it should go somewhere else like UI Events agree we should either close or move to another spec <NavidZ_> https://github.com/w3c/pointerevents/issues/167 #167 Olli these are old IE things that were unspecified Navid: oh i see, as these are updated in mouse events we'd inherit those ... should we call these out that we don't inherit them / set them to null Mustaq: as we're forced to inherit them.... Navid: what's the use case? If authors were to migrate their old legacy code to PE, would they be able to do it in a more standard way? If there's better way for authors (as they already need to update their code), then we should set them to null Patrick: agree ... so are we going to add a note that we blank/null them? Navid: yeah once we've looked at use cases https://github.com/w3c/pointerevents/issues/165 #165 Patrick: not married to the idea Navid: this is related to UA ignoring/cancelling multiple pointer events maybe you can look at that note and see if it can be added there Patrick: sure <NavidZ_> https://rawgit.com/smaug----/test-results/d2b1bcc451c5b85d2b1d0cb721a2f732b3c01120/pointerevents/less-than-2.html NAvid: would like to go over test results for rest of call ... new touch action behaviors in chrome, not in any other browsers do we want to keep them? Olli: should move them to v3 Edge doesn't have those either Because I believe Edge's results only cover automated tests at this point Navid: you do have the tangentialpressure attribute (but no value), right? <smaug> https://bugzilla.mozilla.org/show_bug.cgi?id=1292064 Navid: you're passing a test we fail (movementxy). do you have fractional coordinates in Firefox? we are failing it because pointerlock hasn't updated yet Olli: yes we're failing that as well. need to revisit those results ... still waiting to get a pen device to run manual tests Navid: we have 15 issues left, (and 25 assigned) so we can cover those next week Summary of Action Items Summary of Resolutions [End of minutes] -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 21 March 2018 16:07:50 UTC