- From: Peter Linss <notifications@github.com>
- Date: Tue, 02 Apr 2019 17:31:56 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 3 April 2019 00:32:19 UTC
@ojanvafai yes, while I'm not proposing any specific syntax, that's the idea I was trying to get across. Rather than delegate the gesture, delegate what the gesture enables, this way we're not tying the specific feature that's being enabled to a gesture or any other mechanism, just the fact that the feature has been enabled (because the mechanism for enabling the feature can/will change or be UA specific). It also gives the author more fine-grained control about what can be done in the delegated iframe. Also, related, rather than have an API that exposes the fact that you've been "user activated", expose the fact that the specific features controlled by the activation state have been enabled (and disabled when the gesture has been consumed or no longer applies). This can either be done by the existing permissions API or by augmenting that API as needed for the transient nature of the permission. I understand that the features we're taking about here (so far) are the ones currently controlled by user activation, but why not have this be the same mechanism as delegating any other permission? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/347#issuecomment-479271255
Received on Wednesday, 3 April 2019 00:32:19 UTC