Draft minutes: PEWG 9 November 2016 call

Minutes from today's call are available here


and copied below. Please send any corrections within the next 6 days. In 
the absence of any changes, these minutes will be considered approved.



09 Nov 2016


See also: IRC log


patrick_h_lauke, shepazu, teddink, Mustaq_Ahmed, scott_gonzalez, 
Navid_Zolghadr, dtapuska

Define ordering of lostpointercapture and pointerout/leave for touch
Need to clarify what triggers boundary events when releasing a capture
pointerup pressure should always be 0
How should touch-action behave for span
How should touch-action behave for span?
Add explicit control over pinch-zoom to touch-action
Stylus eraser: should it be a new pointerType instead of a button state?
Summary of Action Items
Summary of Resolutions
anybody up for scribing by any chance?

Define ordering of lostpointercapture and pointerout/leave for touch


Navid: this looks correct, but wanted to check

mustaq: yes, we just need to add a test

Navid: should be quick

Ted: that sounds fine, we're happy to have touch and mouse match in this 

Need to clarify what triggers boundary events when releasing a capture


Associated PR: Clarify the hit test and capturing target for boundary 
events https://github.com/w3c/pointerevents/pull/154

Navid: ...we wanted to make this more precise/clear so tweaked the 
wording. do you think this correctly covers the case now?

Patrick: just look over this in next couple of days

happy to merge once we're all happy

pointerup pressure should always be 0

Patrick: as we had full consensus, I merged this

How should touch-action behave for span

How should touch-action behave for span?

<NavidZ> https://github.com/w3c/pointerevents/issues/150
Navid: we wanted touch action to work for inline elements, but we 
changed that. but test still tests old behavior

should i remove test altogether, or change it to not have an effect

?: yes changing it to have no effect would be best

as it's not directly referring to anything normative in text, it 
shouldn't be v2-blockingMustaq

Navid: i don't think it's going to take a lot of time, we want it for 

dtapuska: there's also things like rows/columns/cells, we should have 
tests for those too

Navid: we have a few tests, but not for all those elements/cases
... we need to clarify/look at some of the CSS tests in web platform

we should be closer to CSS tests, as that's what we're testing

Navid: do you know any tests that look relevant?

dtapuska: i'll send some over

Navid: i'll dig in more and try to get tests that reflect inline element 

Add explicit control over pinch-zoom to touch-action


Associated PR: Add pinch-zoom token to touch-action 

Needs feedback from Ted/MS Legal

Ted: unfortunately we still need to avoid pinch-zoom as a term

as group, our charter explicitly says we won't be spec-ing gestures, so 
would be hard to claim pinch-zoom not a gesture

so we'd need to check our charter

dtapuska: it's a two-finger manipulation...

Ted: i couldn't get this past legal team atm, though i get it/agree with you

part of it has to do with specific IP that makes it challenging

Mustaq: do we have suggestion to move forward?

dtapuska: what is next check-in date? has legal definitely said no or 
still investigating?

Ted: definitive no. there might be a change of mind in future, but 
nothing imminent

Patrick: so is there an alternative name we can use, or really 
fundamentally the fact that it's a gesture?

dtapuska: [discussion on gesture versus single/two finger manipulation]

Ted: it would be an uphill battle due to vague language used in IP

happy to try, but not hopeful

not sure it matters if we implement it as de-facto behavior, not spec'd

as long as we're interoperable, but it's not defined

dtapuska: are we ok having it as web platform tests, even when it's not 

i wrote some de-facto tests, but not put them in the web platform repo. 
should we let those in?

Ted: at this point in time, based on wording of charter, we have to pull 
the pull request

for web platform test, my first inclination is no, as it insinuates 
everyone has to pass to get to REC

we would pass because we all have it implemented, but...should we have a 
web platform test for a behavior that's not in spec. feels odd

from a w3c process perspective

shepazu: i should probably chime in. ted is correct from a process 

we shouldn't be doing this, it's outside our charter, for legal reasons

at same time, i feel we should try fighting that fight, but not in that 

potentially a better place would be WICG, make a small spec that extends 
that spec

as that's a place the IP holder is involved. it's a long battle, but 
it's more appropriate there

suggest we put it in some repo. web platforms test not meant to reflect 
w3c process, but rather interoperability aspect of testing

w3c testing about demonstrating implementability of spec

contrast that with getting interoperable implementations

having a test, having it outside our repo but on webplatform, not 
associating it with this spec but say "this is to test an 
interoperability aspect"

idea of having these de-facto standards and not specifying them anywhere 
due to legal reasons ... violates W3C perspective

we really should get it cleared from IP perspective. we all know who/why 
that's a problem, but we really shouldn't punt on it

but this group doesn't have the IP clearance to do it

rather than slow/halt this group (with a PAG), we should take out the 
feature, put it somewhere else, and push there. but we SHOULD push the 
issue - here's this thing, here's a test. even if no IP commitment, it's 
documented with a test

and separate incubator spec

there's probably other such cases we want to spec out

perhaps we could gather these under a gesture spec, in a community 
group, then incubate it

and see if we can get some better IP situation going forward

Mustaq: ok to have as separate doc in same repo or problem?

shepazu: it would be a problem

Mustaq: we did an extension (for the coalesced points API). ok to do 
same with this in our repo?

shepazu: as long as we don't publish it as part of the TR, fine. we can 
keep working on this, but need to be clear we can't publish as part of PE

it could be a NOTE, need to check

second part: would group members be comfortable doing that? and 
microsoft would probably say no. i can't speak for MS, and Ted perhaps 
may not be able to either

Ted: we need to be cogniscent in group that work on anything that smells 
like a gesture wouldn't be publishable

move it to incubator group, gives us clean separation, doesn't raise 
eyebrows...but IANAL

shepazu: maybe i should look into this and come back with suggestion

going to be leaving w3c at end of year, won't be the one who'll help you 
resolve this, but will check with colleague at w3c and get back to you

Patrick: in meantime, should we close issue/PR?

Ted: i think we can leave it open to ensure it doesn't fall between cracks

Stylus eraser: should it be a new pointerType instead of a button state?


Patrick: i lost track of where we are at

Mustaq: [gives quick overview of current situation about hovering 
pointer and eraser]

on Surface, hovering pen with button press doesn't fire event (?)

Navid(?): the correct behavior will depend on the application and how it 
wants to handle things like hovering pointers/clicks/eraser

Mustaq: but we want to make the API intuitive. current way doesn't seem 

Navid: if i was drawing, and press the eraser button, you'd need to fire 
pointerout/pointerleave for the pen, then pointerover/pointerenter for 
eraser type pointer. and it may cause a click along the way


Navid: the pens that you flip over, you'd naturally see the pen leave 
digitizer area, then you'd see the eraser appearing

if we kept it as just type=pen, the second step you'd see the pen 
reappear but with the eraser button pressed?

Mustaq: ... there are many small solutions, but we should get more 
feedback and possible approaches

Ted: not spent enough time with pen interface to work out the finer 
points, but plan to

Navid: worth seeing how drawing apps handle it

Ted: i can have chat with our OneNote team for some feedback

<mustaq> http://lazynezumi.com/
<mustaq> "Position Smoothing"
<mustaq> I think eraser mode has some use case similar to this.
<mustaq> Eraser mode being active always makes it impossible.
Navid: as we have all v2 blocking issues now addressed with relevant 
PRs, are we happy to move to next step?

Ted: i don't see why not

Navid: should we call the meeting

Patrick: yes we seem to have addressed all issues

thanks everybody. meeting next week unless you hear otherwise on mailing 

Summary of Action Items

Summary of Resolutions

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/11/09 16:48:36 $
Scribe.perl diagnostic output

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, 9 November 2016 17:03:06 UTC