- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 27 May 2020 16:53:38 +0100
- To: public-pointer-events@w3.org
Dear all, minutes from today's call are at https://www.w3.org/2020/05/27-pointerevents-minutes.html and also copied below: Topics: - should altitudeAngle default to 0 or pi/2 when not supported? https://github.com/w3c/pointerevents/issues/320 - It is not possible to generate one set of angle values from other set https://github.com/w3c/pointerevents/issues/321 - Translate between tiltX/tiltY and azimuth/altitude https://github.com/w3c/pointerevents/pull/322 - Virtual TPAC F2F <scribe> Scribe: Patrick H. Lauke - add altitudeAngle/azimuthAngle https://github.com/w3c/pointerevents/pull/316 - this has been merged, but led to some further questions - should altitudeAngle default to 0 or pi/2 when not supported? https://github.com/w3c/pointerevents/issues/320 Patrick: giving overview of the discussion around Touch Events using 0, potential confusion if default in PE is pi/2 navid: mentions argument that we had around pressure, and how we decided to go for 0.5, to make PE "immediately usable" without having to special case stuff so using pi/2 as default would make it immediately usable in the same way using 0 as default would not be immediately usable but pi/2 would be a more sensible fallback other point about conversion: if we use pi/2 it makes it clearer for conversion taking the newer approach - not having azimuthAngle/altitudeAngle properties, but only exposing tiltX/tiltY and the conversion functions, would make this moot Patrick: so we have fundamental question of do we WANT to have azimuthAngle/altitudeAngle properties, OR sticking to original tiltX/tiltY only but offer functions for conversion only how unusual is either approach? looking at other specs? Navid: it seems unusual, but according what Domenic said the first approach is not allowed in WebIDL <smaug> https://dom.spec.whatwg.org/#dom-mutationobserver-observe Smaug: which part of WebIDL does this contravene? Navid: the problem are the default values, we can't define that the defaults need to be backfilled/calculated ... maybe we shouldn't have any default values at all. But mouse etc do now Smaug: looking at mutation event observer, it does define defaults and then (extra processing of how to do it...) Navid: we should not have default values in dictionary, but in PE constructor for previous solution, we should remove default values for the four properties Smaug: and it can be defined in a backwards-compatible way Navid: can stick to original plan, just remove default values. going to be a bit different from other event dictionaries Smaug: think some events have *required* properties. in those cases they don't have default values NAvid: 1) sticking to old solution. have to move stuff to constructor. domenic doesn't like this as it moves logic into the constructor. 2) other solution what liviu did with getter/setter functions / utility functions (though they feel perhaps odd/not related to PE directly) Smaug: both are unusual, event APIs don't usually have this kind of logic Navid: just remove default values of tiltX/tiltY/azimuthAngle/altitudeAngle (from dictionary) Smaug: i think i'm ok with that. spec would need to say something similar to DOM spec for event observer Navid: Patrick you ok with it? Patrick: I'm ok with it...if somebody else does a PR, as it's beyond my understanding Navid: Liviu you ok doing it? Liviu: if we have the 4 attributes, if we convert tiltX/tiltY we don't lose anything (as they're long), but going from azimuthAngle/altitudeAngle to tilt we need some kind of grounding Navid: wonder if we should change tilt, twist, etc to double if it doesn't bite us now, it would surely do later s/grounging/rounding Navid: we need to do some form of rounding already anyway...is that bad? Liviu: don't think it's a problem Smaug: shouldn't be Navid: we already do lose info, not a big problem then first question from Patrick still on table. if device has both values, populate all those values. if one or the other set is not reported by platform, convert the missing one. if none of them are reported/present, then fill in default values Patrick: in principle i like using pi/2. it's more consistent/logical. if we do we need a big warning block in the spec. [some extra discussion about testing on iPad/Pencil and how apple's implementation for PE and stylus is actually spot on, testing with WebGL test] Liviu: one aspect noticed during testing with Chromium - current authors can pass unrealistic values. are we ok with it? Navid: do we want to do any clipping / clamping? Smaug: what happens with conversion? i think it's fine, author responsibility NAvid: what do we do if authors only pass on one value ... say just tiltX Patrick: what happens with mouse events ? Smaug: default value Navid: so we need to define something in the spec that says if only one value in a pair (tiltX/tiltY, azimuthAngle/altitudeAngle) is sent, the other one is default value Patrick: so on the default value for altitudeAngle when no value is passed on by platform, we're agreed that pi/2 makes more sense (and it needs a warning in spec that it's different from touch events) Navid: yes Smaug: yes - It is not possible to generate one set of angle values from other set https://github.com/w3c/pointerevents/issues/321 Navid: this is what we said above. remove default values, and then put in extra logic Patrick: and I think Liviu you said you were going to do it Liviu: yes - Translate between tiltX/tiltY and azimuth/altitude https://github.com/w3c/pointerevents/pull/322 Patrick: so as we're going tthe other way, we should close this one? Navid: hopefully we won't hit any more issues around this, but for now yes <NavidZ_> I agree. Let's close it Patrick: one extra aspect I wanted to mention Virtual TPAC F2F Patrick: I completely missed the original deadline for responding about whether we wanted to have a specific time set aside for PEWG at virtual TPAC or not. Feel personally that, as most others are involved in far larger/more important groups that do benefit from structured virtual F2F time set aside compared to our small group, we're ok not to formally have a time set aside at the virtual TPAC and carry on working on github and our semi-irregular calls to coordinate Navid: I'm ok with not having a time at virtual TPAC, but would like to stick to TPAC timeline for roughly finishing up PEv3, and then maybe as discussed see if we want to morph into community group Patrick: agree. also i think azimuth/altitude is the last big new feature we want. can't see any more big features we'd want to cram into a potential PEv4 How about you Olli, you ok with not having a formal meet at virtual TPAC and to aim for that time for finishing PEv£? Smaug: yes Patrick: ok, think that's it for today. We'll meet again in 2 weeks or 4 weeks, depending on progress on github issues here. -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 27 May 2020 15:53:53 UTC