- From: Gary Kacmarcik <notifications@github.com>
- Date: Wed, 04 Oct 2017 19:04:31 -0700
- To: w3c/clipboard-apis <clipboard-apis@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/clipboard-apis/issues/51/334338798@github.com>
**Q1** *Approach 1* The main disadvantage mentioned here is effectively saying that Approach 3 is preferred. Unfortunately, there are issues with doing that for the clipboard API (see discussion under Approach 3). WRT the concerns in [Permissions #83](https://github.com/w3c/permissions/issues/83), I think including text in the specification to the effect of: > "Normally, you will not need to call the `request()` method directly because the clipboard APIs will automatically request permission as appropriate. Scenarios where you might need to use this method include ..." ...would be sufficient. *Approach 2* Per the description above, while Approach 1 "provides a clear way" for developers to use it, this approach has parts that are "non-obvious to developers" and others parts that are "not clear" or "unnatural". Personally, I think this is a poorer API design because it only makes a subset of the intended usage easy and makes other intended usage awkward and non-intuitive. Note that the stated advantage of this approach ("permission elevation is implicit in the API") is also true in Approach 1 for the standard use cases. *Approach 3* In our case, the `request()` call can't return a handle to a resource because we need this Permission to apply to the already-existing sync clipboard APIs (which are not accessed via `navigator.clipboard` so they wouldn't have the right scope) and the `clipboardchange` event. I think the best we can do here is to return a Promise<bool> that indicates success. However, I agree that this would certainly be the best approach if we were starting from scratch and didn't have to worry about the existing clipboard APIs. So, my preference here (for Clipboard) is for Approach 1. **Q2** Approach 1 seems straightforward and gives the UAs flexibility to do what they need to do. The gesture requirement can't be queried, but I can't think of a use case where that matters. WRT Approach 2, I'm a bit concerned about how that complicates the Permission UX for the user, e.g.: how a UA would describe the difference between them and how it would decide which permission to use in calls to `clipboard.read()` and `.write()`. I don't have strong opinions on this, but I think that Approach 1 is sufficient unless we have a use-case where the Permission granularity of Approach 2 is required. I'll also note that taking Approach 1 now doesn't preclude adding a Gesture dimension to the Permission descriptor at a later time. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/clipboard-apis/issues/51#issuecomment-334338798
Received on Thursday, 5 October 2017 02:04:53 UTC