- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 7 Aug 2019 17:18:49 +0100
- To: public-pointer-events@w3.org
For some reason, the RRSAgent generated minutes ... don't seem to have been generated (should have been at https://www.w3.org/2019/08/07-pointerevents-minutes.html) A rough dump from IRC is below: Meeting: PEWG Chair: Patrick H. Lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2019JulSep/0029.html Scribe: patrick_h_lauke present+ patrick_h_lauke smaug: present+ Olli_Pettay ella: present+ ella NavidZ_: present+ NavidZ Topic: tiltX and tiltY aren't as helpful as just having altitude angle https://github.com/w3c/pointerevents/issues/274 Navid: do we want this polyfilled, or provided by platform? Patrick: concern is polyfilling client-side could be performance hit Navid: browsers could internally calculate as needed/accessed Patrick: would it make sense to have both these sets of variables? does it go against some kind of API philosophy? Olli / Navid don't see any major problems Olli: DOM API has many ways of achieving same thing, not a problem Navid: do we need to spec what happens if an author changes just one like tiltX, that it needs to be recalculated? Olli: but these are read-only values, so can't be modified may need to specify the calculation between the two Navid: what about constructor? do browsers need to guarantee if constructed that both sets are equivalent Olli: if you pass them all, i would expect all those values to stay, but if author only provides one set or the other, then browser calculates the missing pair Navid: what if we don't guarantee anything? either they do it properly and provide everything, or not. browser doesn't try to backfill Olli: maybe that's fine. if it's not trusted events, created by webpage, then just use values passed in constructor. it's simple, and then up to dev Navid: so formula we present in spec is only for trusted events Patrick: who wants to have a stab at PR [discussion on github process] Patrick: I'll make an initial commit, think I have the formula for conversion we'll make an initial PR with a commit and iterate over that so that Microsoft can also comment/contribute, don't want to move ahead without them Topic: 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 Navid: we had criteria that pointer needs to be active for release etc, but we haven't defined what activeness means i.e. if we have iframe, and pointer goes over it, does the iframe see the pointer as active? does the iframe see the pointer as active and can capture it, or not? Olli: i'd say this is defined in spec. 10.2 is quite clear not against behavior of blink, but it's different from what the spec says Navid: where in 10.2? Olli: activeness is not defined, there's no limitation similar to what blink does currently blink has some limitation / custom behavior, but spec doesn't define it Navid: correct blink goes beyond what spec says Olli: not against adding definition to spec, but need to be clear about which document we're referring to Navid: the case about passing pointer id via postmessage? Olli: if you have same origin, you could do it directly Navid: if you're out of process/cross origin, and somehow get ID, you should not be able to just pointercapture? if you allow that, an iframe could just randomly capture random numbers Olli: could be useful, could be valid cases, but also possible to do bad things Patrick: i seem to remember early discussions around advertising iframes doing nefarious things Olli: for same origin, it could be ok...but yes blink's behavior seems more consistent with other things Navid: could we explore if there are valid use cases? delegating permissions/capabilities to iframes? does it have enough value? Olli: or we can limit API (to behave like blink?) Navid: can we change that in future though if valid use cases DO crop up? Olli: always safer to start restrictive and then open them up more later safe to change spec now, and then later can change spec Navid: capture only allowed if pointer is seen as active in the current document Olli: defining current owner document may be tricky before event dispatch maybe DOM spec has some kind of hooks how to define this stuff there's something like a target's associated document, somewhere in the algorithm, that could be useful Navid: ok we'll explore further, and i'll comment on issue smaug: https://dom.spec.whatwg.org/#concept-event-dispatch Topic: Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285 Navid: this seems more relevant to UI spec we do talk a bit about how we handle mouse fallback events, but we don't do it for the pointer events themselves should we write more in PE spec, or wait for UI spec to make it more clear, and we then piggy back on top of that Olli: UI spec needs to be clearer Navid: will discuss at TPAC Topic: AOB NavidZ_: Too many other behaviors interrupt pointer events (dragstart, touch-action)<https://github.com/w3c/pointerevents/issues/213> Navid: that's done not much else from last meeting that was progressed would welcome further feedback though - particularly use cases etc (the above in reference to PR Add single-directional touch action values https://github.com/w3c/pointerevents/pull/294 ) P -- 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, 7 August 2019 16:19:14 UTC