Draft minutes: 13 July 2016 call

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