See also: IRC log
urgh
<scribe> scribe: patrick_h_lauke
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
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
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
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
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
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
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]