See also: IRC log
<scribe> scribe: patrick_h_lauke
<teddink> Thanks Patrick - dialing in now...
https://lists.w3.org/Archives/Public/public-pointer-events/2016OctDec/0000.html
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
<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
<rbyers> https://lists.w3.org/Archives/Public/public-pointer-events/2016OctDec/0013.html
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 builds
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 results
[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 interoperably
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.
<rbyers> see above....
<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: https://crbug.com/609363
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: https://github.com/WICG/interventions/issues/12
<rbyers> Navid changed HTML for this: https://github.com/whatwg/html/pull/1875
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: https://crbug.com/607948
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?
[silence]
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?
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Mustaq (?)/Navid/ Succeeded: s/Mats/Matt/ Found Scribe: patrick_h_lauke Inferring ScribeNick: patrick_h_lauke Present: patrick_h_lauke Mustaq_Ahmed Navid_Zolghadr teddink rbyers mbrubeck Got date from IRC log name: 19 Oct 2016 Guessing minutes URL: http://www.w3.org/2016/10/19-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]