- From: snianu <notifications@github.com>
- Date: Tue, 21 Nov 2023 13:03:55 -0800
- To: w3c/clipboard-apis <clipboard-apis@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/clipboard-apis/issues/191/1821676605@github.com>
1. Just making sure that my understanding of this proposal is correct -- You're proposing a new `read()` method that takes a sequence of MIME types as parameter, and the `ClipboardItem` that is returned, only has the data for these MIME types. That way we don't have to check for sequence number as the data for these formats would be read upfront. Correct?
Some concerns with this approach:
- Does the web author have to call `read({formats})` multiple times if the first call for `text/html` failed because the format wasn't present in the clipboard and now the author wants to read a different format? If not, then how does a web author know what formats are present on the clipboard that they can specify in the read option? If the web author has to always read all supported formats, then it kills the benefits of delay rendering and having a Promise wouldn't make much sense in `getType` as the data for all the formats are already present after read.
- If `text/html` & `text/plain` formats are delay rendered by a native app during copy, but during paste, the site prefers to use `text/html` (if present) and add `text/plain` as a fallback option, then they have to specify both in the `read({formats})` method. That kills the benefit of delay rendering as the native app has to produce data for both the formats during paste.
- An example in Excel Online and Google Sheets where paste support pasting multiple options:
Excel Online:
Google Sheet:
If the app doesn't want to read the data at the time of paste but want to show paste options for all supported formats present in the clipboard, then it would be waste of resources if they implement it using the existing `read()` and the proposed `read({formats})` methods that don't support lazy loading of data for the formats.
2. For the clipboard history example, it is highly unlikely that the app would cache all the formats as part of the clipboard history as they are expensive to store in memory (both local and server side). On Windows only plain text is supported by-default in the clipboard history because it is not memory efficient to save images, HTML, high fidelity custom formats etc for all copy operations.
Clipboard history app can still be implemented with the proposed lazy loading of data in `getType` -- it's just that the app would have to call `getType` for all the formats they want to save in the history.
Note that Safari has shipped this behavior, so the site would be broken there if they aren't already calling `getType` multiple times for all formats they want to cache in history. With the proposed change in `read()` and `getType`, it will also help with browser interop.
--
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/191#issuecomment-1821676605
You are receiving this because you are subscribed to this thread.
Message ID: <w3c/clipboard-apis/issues/191/1821676605@github.com>
Received on Tuesday, 21 November 2023 21:04:00 UTC