- From: Kagami Sascha Rosylight <notifications@github.com>
- Date: Fri, 09 Feb 2024 15:34:09 -0800
- To: w3c/clipboard-apis <clipboard-apis@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/clipboard-apis/issues/212/1936739232@github.com>
> Even for formats that are not delayed rendered, this would be a useful addition to the async clipboard API. 👍 > It would be nice not to force web authors to use delayed clipboard rendering if they want to take advantage of this memory optimization for read/write. My understanding was that delayed rendering won't need special flag, was it? Not sure what you mean by forcing. Authors would just pass readable stream and consuming that would solely depend on user agent implementation, right? > Like it was mentioned in [this ](https://github.com/w3c/editing/issues/439#issuecomment-1834546159)comment, this defeats the purpose of delay rendering the expensive formats as the web authors are forced to trigger the callbacks. We [resolved ](https://github.com/w3c/editing/issues/439#issuecomment-1934719705)the privacy issue to only support delayed rendering for built-in formats for now, but we will explore options to extend this support to web custom formats with the privacy mitigation in-place in the future. Stream sources can produce small chunk for each pull rather than big chunk at once, so I think it doesn't defeat the point as each pull shouldn't take long. 👍 for doing builtin formats so that we can keep discussing, though! -- Reply to this email directly or view it on GitHub: https://github.com/w3c/clipboard-apis/issues/212#issuecomment-1936739232 You are receiving this because you are subscribed to this thread. Message ID: <w3c/clipboard-apis/issues/212/1936739232@github.com>
Received on Friday, 9 February 2024 23:34:15 UTC