Re: Draft minutes: 13 July 2016 call

I'm missing from the present list. I think you had a typo when adding me.

On Wed, Jul 13, 2016 at 12:04 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> 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
>
>