Re: [w3c/clipboard-apis] Support for delayed clipboard data (#41)

>This doesn't necessarily mitigate the desire to account for it, but note that Chrome is unlikely to support copying images without browser-side re-encoding for sanitization (that's one major motivation for the asynchronous API). So it wouldn't be beneficial to generate various image formats before passing to the API in that case.

That's fine for our needs, at least. We need this for non-image, binary data (e.g. PDF).

>Presumably most OSes require pushing the data actively to the clipboard. Would it make sense to use a Promise here, since we are directly triggering the write with the API?

[Windows](https://msdn.microsoft.com/en-us/library/windows/desktop/ms649016(v=vs.85).aspx#_win32_Processing_the_WM_RENDERFORMAT_and_WM_RENDERALLFORMATS_Messages), [macOS](https://developer.apple.com/reference/appkit/nspasteboarditemdataprovider), and [Linux](https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html#GtkClipboardGetFunc) all have a way to add format(s) to the clipboard and provide the data only when requested.

-- 
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/41#issuecomment-289631147