- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 13 Jul 2016 17:04:59 +0100
- To: public-pointer-events@w3.org
Hi All, draft minutes from the last PEWG call are available at https://www.w3.org/2016/07/13-pointerevents-minutes.html and copied below. If you have any comments, corrections, etc., please reply to this email within 1 week. In the absence of any changes, these minutes will be considered approved. W3C - DRAFT - Pointer Events WG 13 Jul 2016 Agenda See also: IRC log Attendees Present teddink, NavidZ, Mustaq_Ahmed, Rick_Byers, Dave_Tapuska, shepazu Regrets Chair patrick_h_lauke Scribe patrick_h_lauke Contents Topics Mouse Event compatibility model for touch is incompatible with current practice Pointermove should not require a hit-test by default for touch Add explicit control over pinch-zoom to touch-action What should be the 'detail' property of pointer events? Specify that "click" is a PointerEvent? A possible immedate pointer capture processing Summary of Action Items Summary of Resolutions urgh <scribe> scribe: patrick_h_lauke Mouse Event compatibility model for touch is incompatible with current practice https://github.com/w3c/pointerevents/issues/7 RB: this looks fine to me. if you remember we had different models for mouse (ah i don't think it's actually RB) RB: the touch events spec tries to do something here. it's fine to define what happens on a tap without defining anything else only place we use tap today is inside of a note. what Jacob wanted to do was not to use "tap" in normative portion RB: potentially we should put this (the definition?) in the touch events spec we could have a note here that if touch events are supported, see touch events spec TD: that seems a safe way for me to do it (also have legal looking over use of wording relating to "gesture", may have something in time for F2F) RB: it's not on critical path of what we want for F2F, but we'll address this after RESOLUTION: Rick to add a comment/note on the GH issue, then take it further to Touch Events CG Pointermove should not require a hit-test by default for touch https://github.com/w3c/pointerevents/issues/8 <NavidZ> https://github.com/w3c/pointerevents/issues/61 Navid(?): this is not doing hit testing while tracking touch NZ: this is related to this issue https://github.com/w3c/pointerevents/issues/61 - danger is compat, maybe leave it for the F2F RB: both issues are ship-blocking for us NZ: the second one covers first one? RB: if you do implicit capture, then... NZ: but we don't have any issue about implicit capture? but is issue 8 implicit capture? TD: yes that's the way i saw it, 8 being about implicit capture RB: leaving to F2F to decide next steps RESOLUTION: leaving for F2F RB: F2F is about discussing implementation issues, not a WG meeting Add explicit control over pinch-zoom to touch-action https://github.com/w3c/pointerevents/issues/29 (which has a related open PR https://github.com/w3c/pointerevents/pull/99) RB: i assume this is what Ted meant when he mentioned he was talking to legal TD: didn't take time to take look at it, but yes this will need review by legal for language RB: chrome supporting what edge ships seems agreed as being a good move we can probably get approval to ship, just pointing to MSDN as being a de-facto spec should not block our intent to ship we jumped on this because Scott pointed out that jquery had issues in this area SG: we add touch-ACTION:none to our draggable etc, but doing that you can't use native behavior for gestures like dragging etc RB: disabling pinch-zoom is an accessibility bug - just to get a single-finger draggable, disabling zoom, is overkill SG: the Hammer team would like this as well RB: thinking was that if Edge does this, we should just add this behavior...but it feels like Edge has a bug here too <rbyers> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8094788/ <scott_gonzalez> Edge bug: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8094788/ filed a bug on Edge. something for Ted to get somebody to look at the bug TD: that's my feature team, so sure can RB: maybe it's just misunderstanding what you guys intended with pinch-zoom this is more urgent than legal side. don't want chrome to ship something if i misunderstood the edge behavior RESOLUTION: blocked on edge issue, finding out if bug in edge or if Rick got the behavior wrong What should be the 'detail' property of pointer events? https://github.com/w3c/pointerevents/issues/98 <NavidZ> https://www.w3.org/TR/DOM-Level-3-Events/#event-type-click <NavidZ> https://w3c.github.io/pointerevents/#h-pointer-event-types NZ: is everybody ok with just saying explicitly that we'll send value 0, so we don't change the definition of details and avoid talking about click RB: i wouldn't extend table to do it, but just add as prose in sect 5.2 "all of the above events have details value 0" any objections? TD: go for it PL: good Specify that "click" is a PointerEvent? https://github.com/w3c/pointerevents/issues/100 RB: oli raised good questions. there's also question of logistics of HOW we spec it NZ: depends if sites check type of click RB: if edge shipped it, then presumably no compat impact ted, when did this change happen? TD: will have to circle back with team and check our change list RB: real-world interop problem is not the type of the event, but checking pointerType on events we can't change details inside the event, which is why we can't say (ref previous issue) "all pointer events have details 0", but rather "all the above events have details 0" should chrome just match edge? we should probably not do it until spec clarifies maybe we can't patch HTML spec, but we can monkey-patch PE spec even if it's not up to AnneVK quality found an MSDN reference to this change, relating to IE11 <dtapuska> https://msdn.microsoft.com/en-ca/library/ms536914(v=vs.85).aspx RB: looking at the docs, just confused by this MSDN document Ted what interface defines the pointerType property? TD: don't know offhand DT: you could inject into prototype chain... RB: seems Edge only does this for click, doubleclick and contextmenu outstanding issue to characterize Edge behavior and to answer: element has click method, if i call element's click() what is the pointerType what we do exactly doesn't matter, but we should match Edge behavior RESOLUTION: investigate edge behavior further RB: also questions like "if you trigger context menu with keyboard, is that a PE and what's the pointerType?" [...] argument of event listeners should be prepared that sometimes events could be pointer events. maybe just do it for trusted pointer events RB: sounds like we're coming to some rough understanding, let me write it in the issue on GH DT: we should also consider making drag a pointer event RB: can we keep it as a separate issue though, and first match edge behavior here for click/dblclick/contextmenu Ted can you take this and check if that matches what Edge is doing? filed https://github.com/w3c/pointerevents/issues/106 for drag event question <rbyers> https://github.com/w3c/pointerevents/issues/100#issuecomment-232396438 RB: we probably need to also check other properties, for instance what about isPrimary? should it be true in these cases? for UA generated ones, they'll have their correct values for click() and keyboard-initiated we'll use defaults (updated the comment) PL: sounds ok to me TD: sounds reasonable RB: i'll assing this to you, confirm with edge team <NavidZ> https://github.com/w3c/pointerevents/pull/76 NZ: nothing more on agenda, but wanted to talk about this A possible immedate pointer capture processing NZ: do we care about all the properties like tilt etc for the got/lostpointercapture? apart from id, do we want default just for those thanks shepazu sounds good RB: that's really good question...i'd say "check what Edge does" Mustaq: got got/lost, we probably jsut care about id NZ: the spec should say something explicitly though RB: as long as it's web-compatible...i can't imagine a good use case for devs to know things like coordinates of got/lost pointer capture Mustaq: but this also affects boundary events NZ: need to check if Edge has all properties like coords for got/lost RB: maybe we need to spec that got/lost DON'T have these props NZ: would that be the compat risk though? RB: we should stick to what Edge does TD: added some data in https://github.com/w3c/pointerevents/issues/61 - there are 7 sites that use PE and are potentially listening to lostpointercapture wouldn't be that hard to take look and figure out compat risk / if they're relying on those props (many of those sites end with google.com) RB: things like this that give us more data for useful F2F are most urgent in my view google code seems to be enumerating any known event type, but not sure where used...can't see it being used anywhere TD: this is just static analysis, all it means it just showed up somewhere in code, may not be actually used RB: from quick look at source, play.google.com doesn't seem to do anything TD: for F2F, we're two weeks out, so if you haven't answered to the Doodle, do so for dietary restrictions/preferences let me know, to make sure i can accommodate RB: yandex seems to just fire this using id, but no extra props if Edge doesn't send actual props, we should just say it sends default <teddink> Doodle link - http://doodle.com/poll/9grpa8cew2r7mqwi should really go this way, as i don't think the path of caching last known good values makes sense unless that is what edge currently does PL: we can skip next week's call RB: should we do a call during F2F? PL: can probably do it informally as well RB: so we WON'T have a call, but we'll send a note to list Summary of Action Items Summary of Resolutions Rick to add a comment/note on the GH issue, then take it further to Touch Events CG leaving for F2F blocked on edge issue, finding out if bug in edge or if Rick got the behavior wrong investigate edge behavior further [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, 13 July 2016 16:05:23 UTC