- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 19 Oct 2016 17:08:22 +0100
- To: public-pointer-events@w3.org
Hi All, draft minutes from the last PEWG call are available at https://www.w3.org/2016/10/19-pointerevents-minutes.html 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. W3C - DRAFT - PEWG 19 Oct 2016 See also: IRC log Attendees Present patrick_h_lauke, Mustaq_Ahmed, Navid_Zolghadr, teddink, rbyers, mbrubeck Regrets Chair patrick_h_lauke Scribe patrick_h_lauke Contents Topics V2-blocking 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... V2-blocking 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 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 <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. 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: 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? 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