Draft minutes: 19 October 2016 call

Hi All,

draft minutes from the last PEWG call are available at


and copied below.

If you have any comments, corrections, etc., please reply to this email 
by 25 October. In the absence of any changes, these minutes will be 
considered approved.



19 Oct 2016

See also: IRC log


patrick_h_lauke, Mustaq_Ahmed, Navid_Zolghadr, teddink, rbyers, mbrubeck

test results
Open issue triage
implementation status update
implementation status
Summary of Action Items
Summary of Resolutions
<scribe> scribe: patrick_h_lauke
<teddink> Thanks Patrick - dialing in now...


rick: haven't had much feedback on this.

if there's a bunch of small things, let's just get them out of the way, 
but concentrate on marking big issues as v2-blocking

Navid: concerning getcoalesced, are we in danger of developing different 
concurrent implementations

Rick: ted have you looked at getcoalesced at Microsoft

Ted: we haven't talked about it yet, but even if we did it would be a 
year from now

<smaug> aha, I missed the meeting. Was on lunch when the agenda was sent 
and now busy with other stuff. sorry.
Rick: assuming we want to get to REC in less than a year, that means 
Edge won't be the second implementation

(smaug my fault sorry)

Rick: do we have Mats on call?

Matt: no hard information on where we're up to beyond that things are 
being worked on

(sorry my ears are defo not working today)

Rick: if we get to REC and we see no second implementation is there, we 
can pull it and defer to next version

Already talked to PLH that even after Level 2 is final we want to carry 
on iterating. There are possibilities (move to WICG or similar), but 
that's technicalities. for now, we can move to a branch

Doug: from legal perspective there shouldn't be much impact where next 
version is worked on, as long as effort keeps going

I don't think this group will be needed after this recommendation

Rick: is there a process for what happens after a group is "finished" 
and moves back to incubation?

Doug: things are changing, preferred solution experimentally: once group 
has reached stable point, group will probably shut down and transition 
to CG. then up to strategy team rather than mgmt team on when/how to 
move to further standardisation

there will likely be further "supergroups" (CSS etc) who will then take 
up actual legal work of consolidating mature technologies from CG into a 
standardisation WG

Rick: is there anything stopping CG to keep iterating in the same GitHub 
repo as the actual WG even after it's transitioned?

Doug: there is no legal status concerning the repos. Correction: there 
is a *checker* to see that nobody who hasn't made legal commitment is 
making commits, but beyond that no issue

Rick: so easier to keep separate file in the same repo, or use a branch?

File would make it easier as no hassle with single gh-pages branch, 
merging, etc

test results

<rbyers> http://w3c.github.io/test-results/pointerevents/all.html
Rick: looks confusing at the moment as Chrome appears not to pass tests, 
but it's because tests have been moved/improved

we need to look at rerunning tests / clean up. Ted have you looked at 
the tests/rerunning them?

Ted: no, but will take on as an action to discuss with our team, 
particularly as there have been changes

Anybody interested in IE11, or just Edge?

Rick: only Edge. ideally replace IE test results with Edge results, to 
show which are currently failing

Ted: do we have to do a PR?

Rick: yes Navid can share details on how to do it (execute a runner, ...)

If we can have at least two results for each that would be ideal. We can 
then decide if we want to drop older ones

we should have what's shipping in Chrome vs what's currently shipping in 
Edge. Once Firefox ready to ship, they should have results there

should probably remove FF results as tests have changed enough, until 
they have new results corresponding to what's actually shipping. unless 
Matt or anybody else disagree?

<mbrubeck> sounds good
Doug: i don't necessarily disagree, but aren't there some tests that 
they pass?

Rick: sure, but ideally they should rerun their tests/results. although 
we automated this, you still need to run your own local tests first

Navid: ... shouldn't take more than an hour to set up test harness and 
run tests ...

Rick: what we have there is Level 1 based on Firefox Metro build. So it 
was specific, not useful at this stage for Level 2 and current overall 

would be good to see PEP results too (?)

Scott: we have extra layer of injecting PEP before we can run tests

Rick: you can generate the results however you want

we know there are some tests you won't be able to pass, but would be 
good/interesting to see the passing ones anyway

we need at least 2 UA implementations, plus PEP would be interesting/extra

Scott: we made an update recently that made our tests/results 
incompatible with the W3C system, but once that's fixed we'll submit our 

[discussion on subtle differences in implementation in android, 
chromeOS, in edge cases]

Rick: we should be mostly green, with reds annotated (if platform does 
not support particular features)

Doug: we only ask for 2 interop implementations of features. Not testing 
for ubiquity, but that the spec is "implementable interoperably"

"we got this feature right, so now it's time to freeze it", rather than 
"this feature is useful everywhere"

to get to REC, demonstrate that it's implementable interoperably, and 
evidence is usually having 2 interoperable implementations

Rick: if there's enough difference by time we get to REC, let's add 
other column to differentiate/note "test results for chrome/android, 
chrome/windows, etc"

hopefully by then we'll have automated results

Doug: two issues - passing minimum 2 implementation threshold, and other 
making sure it's a feature that's solid/available on the web platform 

keep doing the test side even once in incubation for the second aspect

Rick: valuable to do a triage pass on the call, or iterate on github?

Patrick: looking at time, probably best to at least start on GH

Rick: when do you think you'll have time?

Navid/Mustaq: probably for next week

Rick: we'll do a triage pass with google's perspective, encourage others 
to do the same, then we can pick up on next call

Ted: sounds fair

Patrick: +1

<teddink> Sounds good - I will try to do the same on the Microsoft end.
Open issue triage

<rbyers> see above....
implementation status update

implementation status

<rbyers> Blink has had 3 ship-blocking issues:
Rick et al: implementation proceeding, minor bugs/fixes

<rbyers> Pointer events for touch no longer take a user gesture: 
Rick: annoying one, as it's a not well documented part of web platform
... user gesture - heuristics in browsers, not well standardised today

<rbyers> Some general discussion here: 
<rbyers> Navid changed HTML for this: 
Rick: any discussion on this? interop risk, wanted to write tests, but 
as definition is so loose it's difficult to actually devise tests. but 
it's not THAT serious

other ship blocking bugs around setPointerCapture API

<rbyers> Next ship-blocking bug: "setPointerCapture API throws invalid 
DOMError inside iframe: https://crbug.com/653860
<rbyers> .. Navid has a fix, expect it to merge to M55 soon
third one - would be interested in people's take on this. do we 
understand Edge's behavior?

<rbyers> 3rd bug: PointerEvent should have fractional coordinates: 
Navid: we seem to be on same page for this

Rick: are there any changes for PE on this? Or is it all about UI spec?

<mustaq> Yes, it's a UI spec issue.
risk here: we do report fractional coords for touch events, but not for 
PE. so if devs use TE and get nice smooth curves, and then follow our 
advice to use PE instead, they'll regress

Rick: even once web platform updates, mouse events themselves will 
likely keep integer for compat, but for the same movement in pointer 
events devs would get fractional

big picture: few bugs fixing, but on track to ship in 55. branched, any 
any new changes will go in 56

55 expected stable early December

Rick: can ask on list about Firefox, but assuming ... Matt doesn't have 
any updates?


Rick: ted you showed us build at TPAC. any idea when those changes go live?

Ted: i have reason to believe they'll be in a flight that will go public 
in nov

may have already gone out in a flight that went out early nov

implicit touch stuff may have gone out in october flight

may already be out there

Patrick: does that mean Insider build?

Ted: yes. we don't have official larger version release planned, but all 
these are indeed in insider builds

what's still missing is some of the about://flags capabilities to turn 
things on/off. hopefully all toggles will be in for nov, but not sure

handful of bugs remaining, but need to follow up on them

suspect we'll have them done before final relase, but need to follow up

Navid: after TPAC we wanted to see also see about implicit/explicit 
capture and boundary events. assume these issues will still be in these 
upcoming flights?

Ted: yes no change has been made

Patrick: quick question about added properties twist and 
tangentialPressure. will they appear at some point soon in Chrome 55 / 
Edge ?

Rick: we would want to add them once we have at least one platform that 
supports it

we don't have bugs tracking this probably...

Patrick: even if there's no actual plumbing, is it likely 
mozilla/microsoft could add the props just with default values?

<NavidZ> Here is the bug in Chrome for those properties: crbug.com/649376
Ted: at least a year out for proper implementation at best. properties 
COULD be added early spring but that would be aggressive. will probably 
get scrutiny as it's a new API

Patrick: ok, nothing urgent, just wondering

Rick: if there are no further issues, should we call it?

Summary of Action Items

Summary of Resolutions

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, 19 October 2016 16:08:46 UTC