Re: [w3c/editing] Should we modify the clipboard API spec to match Safari's behavior for HTML-referenced media? (#285)

One possible concern with the opt-in approach is that it would let websites combine file paths with file contents by getting both the unmodified clipboard contents and the one where file: URLs have been replaced with blob: URLs. But that probably isn't too much of a problem.

An opt-in API like that does seem better than coming up with some kind of magic auto-revoking blob URL though. My problem with some kind of auto-revoking mechanism would be that if we're defining something that behaves in some ways very different from blob: URLs, we probably should not pretend they are blob: URLs, but instead have something separate (although having more URL schemes isn't great either).

One downside of blob URLs is that at least in the current chrome implementation there isn't really a way to get the Blob out of one in an efficient manner. I.e. you can fetch or xhr it, but that will still download all the data and creating a new blob out of it, rather than simply creating a reference to the existing blob. That's of course just an implementation detail, and something that could be fixed if that is important (although it is observable in some cases if a reference to an existing blob is returned, or a new blob is created with the same data; so changing the implementation like that is not entirely risk-free).

-- 
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/editing/issues/285#issuecomment-818443461