Pointer Events WG

13 Jul 2016


See also: IRC log


teddink, NavidZ, Mustaq_Ahmed, Rick_Byers, Dave_Tapuska, shepazu



<scribe> scribe: patrick_h_lauke

Mouse Event compatibility model for touch is incompatible with current practice


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


<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


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


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


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

  1. Rick to add a comment/note on the GH issue, then take it further to Touch Events CG
  2. leaving for F2F
  3. blocked on edge issue, finding out if bug in edge or if Rick got the behavior wrong
  4. investigate edge behavior further
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/07/13 16:03:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/event handlers/event listeners/
Found Scribe: patrick_h_lauke
Inferring ScribeNick: patrick_h_lauke

WARNING: Replacing previous Present list. (Old list: scott_gonzalez)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ teddink

Present: teddink NavidZ Mustaq_Ahmed Rick_Byers Dave_Tapuska shepazu
Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2016JulSep/0076.html
Got date from IRC log name: 13 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/13-pointerevents-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]