> Of course it would be nice to support a script that wants to generate random
> HTML with embedded files to place on the clipboard (although I think most of
> those use cases can already be met by using URLs and assuming that any
> software reading HTML from the clipboard can understand URLs..). However, one
> can imagine a use case for example with a CANVAS app where the script wants
> to copy the state of the CANVAS as an image inside HTML it places on the
> clipboard - having the script create src="cid:n" type markup, append files,
> and make the UA translate that to the platform's native clipboard
> implementation's way of referencing one part on the clipboard from another
> part..
I was thinking about images that aren't available cross-domain, like Facebook
pictures. If you copy them, Facebook could use CID to place them on the
clipboard since a Facebook URL wouldn’t be accessible to an email client that
receives the pasted content.
> document.addEventListener('copy', function(e){
> // So, you want to copy the current status of your game? No problem.
> // Let's say this game generates a number of PNG graphics from CANVAS
> tags
> // and keeps them in memory in ArrayBuffers or something
>
> var html = '<div><b>player</b>\'s medals: <img src="cid:1"><img
> src="cid:2"></div>';
> e.clipboardData.items.add(html, 'text/html');
> e.clipboardData.items.add(new File(medals[0], 'medal.png',
> {type:'image/png'}));
> e.clipboardData.items.add(new File(medals[1], 'medal.png',
> {type:'image/png'}));
> e.preventDefault();
>
> }, false);
This seems like we're depending on add() working in a precise order, which
seems vulnerable to code changes or other issues. Maybe add() should return the
location in the list where the item was added, and then it can be used with CID
more safely? I know this is part of HTML5 not ClipboardAPI though. Thoughts?
> Second, can you provide the javascript for how a site would put them into the
> pasted markup during paste?
> The way I thought this would work, would be that the site starts XHR uploads
> from the paste processing, and shows some intermediate 'loading' animation or
> something before it gets the final URLs back from the server. A bit like this
> (although some things could be more elegant, like the insertion of the data
> which needs to take cursors and selections into account):
> http://jsfiddle.net/2Qqrp/
> Thinking about it, it may be considered somewhat wasteful (or exceedingly
> slow - if for example the embedded data is a video) to do it this way - but
> it quickly gets complex and/or confusing if we have a some "show this local
> file until it's uploaded, then reference the online file instead" magic..?
This generally makes sense. If sites prefer to use local dataURI or blob, they
can use the blob URL, and then upload the file later (like in an email
scenario). This means they don't have to wait for them to be on the server
before displaying them. If they want to upload them first and use the server's
new URL for them, they would need to do what you're saying.
-Ben
