- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 2 Oct 2019 16:51:49 +0100
- To: public-pointer-events@w3.org
Dear all, minutes from today's call available on https://www.w3.org/2019/10/02-pointerevents-minutes.html and posted below PEWG 02 Oct 2019 Agenda Attendees Present patrick_h_lauke, plh, NavidZ, Olli_Pettay Regrets Chair Patrick H. Lauke Scribe patrick_h_lauke Contents Topics any relevant corridor/side discussions at TPAC (since we didn't have an official meeting there this time) merging extension into main spec https://w3c.github.io/pointerevents/extension.html tiltX and tiltY aren't as helpful as just having altitude angle https://github.com/w3c/pointerevents/issues/274 Setting pointer capture on an element in a parent frame when the pointer was made active in a child frame https://github.com/w3c/pointerevents/issues/291 Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285 Summary of Action Items Summary of Resolutions <scribe> Scribe: patrick_h_lauke <smaug> webex is so not working for me we'll wait for you smaug any relevant corridor/side discussions at TPAC (since we didn't have an official meeting there this time) Navid: proposal that microsoft had to send click/auxclick etc as pointer events chrome has this behind experimental flag for a few months not had regression/bug reports, either because they're fine or low usage we actually went with more aggressive version, where click etc are actual PE with fractional coordinates we should define what it means for the other properties in PE e.g. pointerType, if it comes from the keyboard we could set to empty string need to come up with a number for pointerId wonder if we should say pointerId '0' value is the "we don't know" origin/value (e.g. generated by keyboard) wondering what others think about that we have normative language about pointerId can be recycled/reused. what happens then with click that comes after pointerup/pointerdown/etc define WHEN ids can be recycled (until the whole event sequence is dispatched, including compat mouse events and click) Olli: right now pointerId zero can be used for anything else so can't really use it gecko uses zero already so can't be made special just now wonder if we should use max value (it's LONG not Unsigned). could we use "-1" ? Navid: we should double-check with other implementations if they ever assign negative pointerId Olli: sounds like a good initial idea [pointerType empty and pointerId=-1] Patrick: also like conceptually that pointerId="-1" kind of implies "this is (likely) not an actual pointer" as it feels conceptually a bit dirty that keyboard would fire a pointer event Navid: ok, we'll run a test in chrome, do a PR to spec, and we look if we get regressions etc ... other topic discussed was longer discussion from Daniel Libby about pointer event trail - he filed issue about it in GH asking underlying API to generate trail under pointer [gives more details about the proposal - web app declaratively requesting platform draw a particular trail with certain characteristics] reduced latency of this approach saw demo on iPad at 120Hz and on MS tablets. just drawing "shadows" half of latency on Surface (at 50Hz) compared to iPad (120Hz) but if only on windows, not the way to go don't recall if Apple said they have similar API Google plan to talk to Android etc platform to check if such a low-level API that can be hooked into exists question is heuristics, legality, and whether it fits into the PE domain or not Olli: it probably fits into PE as you should be able to use it with all pointers...but if not all OSs support, could/should browsers support it themselves (sending coords to their internal compositor, improving latency/performance a bit) is that doable in chrome Navid: forgot to mention that, already discussed with team, and it would also work/improve performance worth shipping, EVEN if it was only platform native on Win and other platforms do it in browser? Olli: still need to iron out issues like cross-origin iframes etc Patrick: wondering if it's not scope creep to cram this into Pointer Events spec itself - thinking for instance PointerLock spec which is separate Navid: concern also with exclusions/IP, so it might prevent us from doing it as part of PE but it should build on top of PE <plh> --> https://www.w3.org/2018/12/pointerevents-charter.html#out-of-scope Out of Scope Patrick: agree, might be worth making extension/incubating further updates from TPAC? [Olli mentions pen action idea that was discussed] Navid: event pointertype CSS definition (?) expanding touch-action to have support per pointer type. will file something on mailing list/gh Microsoft will write an explainer for it Mustaq told me that CSS folks wouldn't like this to be part of CSS, as these are not about rendering but targetting of events merging extension into main spec https://w3c.github.io/pointerevents/extension.html Patrick: are we happy to go ahead with merge, and then go for First Public Working Draft stage Navid: we have some aspects that are handwavy in current text in extension. are we happy with it for now, or do we want to make it more algorithmic like similar specs, rewrite portions to formally and precisely do it Olli: that would all depend on Gary's UI event rewrite Navid: when PE started, it was right before UI events stuff. we started having UI events relying on us in terms of dispatch algorithm one thing we can do with FPWD is be ok with what we have now and hope for best/tweak plh: do we have any test for this? Navid: yes plh: then i say merge it Olli: +1 Navid: going to send PR and have Webkit folks also look at it. deadline of about 1 month? plh: yes and then we can publish FPWD ... when you do merge, can you also move test as appropriate? Navid: yes, will sync tiltX and tiltY aren't as helpful as just having altitude angle https://github.com/w3c/pointerevents/issues/274 PAtrick: this is mostly a wrist-slap for myself as i promised i'd do a basic PR, but not got around to it. hope to have for next meeting Setting pointer capture on an element in a parent frame when the pointer was made active in a child frame https://github.com/w3c/pointerevents/issues/291 <NavidZ_> https://github.com/w3c/pointerevents/pull/300 Navid: i had this pull request... that's current proposal, it seems that people are ok with it? Olli: commented on it but not reviewed again Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285 Navid: briefly discussed with Gary will be dealt with in UI events bigger undertaking than just PE suggestion: don't touch it for now Olli: was also mentioning to Gary, and it's UI events issue about better algorithmic spec do we have a matching UI-events issue? if so we could just link Navid: don't see an issue, want to create one? Olli: i'll create one Patrick: and we leave ours open to see what comes back -- 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, 2 October 2019 15:52:12 UTC