Re: [w3c/clipboard-apis] Read Blob data for the supported formats on-demand during getType. (Issue #191)

@evanstade We discussed with our Excel partners about the concerns you raised in the last EditingWG meeting and have some questions that we would like to discuss in the next meeting:
1. Reading the data for a format on-demand on `getType` is required for delay rendering. Without this, delay rendering of formats doesn't provide any value as the callbacks for all formats would be triggered when the `read()` is invoked. However, just like delay rendering, we could make the lazy read of formats opt-in by adding a new option in the read() method like you mentioned in [this ](https://github.com/w3c/clipboard-apis/issues/191#issuecomment-1817228770)comment. Would that be a reasonable compromise?
2. If we make it optional, then does this lazy read get enabled by-default when a site wants to support delay rendering? e.g. if site A provides callback for couple of formats during copy and site B calls `read()` without providing the lazy load option, then does the lazy load get activated automatically for site B? If so, then does it make sense to provide an option when in some cases it can't be optional?

I agree that providing more delay between `read()` and `getType()` would affect the reliability of the APIs as clipboard can change between the two read steps. But, with the read-all formats approach, `getType` that returns a Promise to a Blob seems unnecessary as the data is already available after the `read()` call. We could also add a `clipboardchange` event so the web authors know when the clipboard has changed, but I'm not sure if it would solve the reliability issue. Thoughts?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/191#issuecomment-1899375038
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issues/191/1899375038@github.com>