Re: Moving Clipboard API spec forward

Siterer Hallvord Reiar Michaelsen Steen <hallvord@opera.com>:
>> It would be nice to understand what needs to be done to get the spec to
>> Last Call.

I've checked in some changes. I guess we're getting there..

> Plan:
> * Find a way to test the   
> clipboard-content-that-embeds-other-clipboard-content scenario (do   
> any other types of software even place such content on the   
> clipboard?) and make sure the spec is sane. In practise, this is   
> mainly about HTML content that embeds IMG not linking to a file://   
> or web URL.

Not done yet. Does anyone on this list know details of software that  
places "complex" payloads on the clipboard? For example, if you in a  
text editor makes a selection that includes an image, then copy - how  
is the image described in the HTML part put on the clipboard? Does it  
matter if image is loaded from a URL / from file / pasted?

> * Clarify the intention that document.execCommand() can be used to   
> trigger real paste / copy actions (with due limitations for security  
>  and privacy reasons) - I think the spec fails to state this clearly  
>  enough

Clarified, hope it's clear.

> * Remove the "cross-origin HTML paste sanitization algorithm" and   
> all references to it (lacks implementation)

Killed.

> * "Calling setData() without calling preventDefault() has no effect,  
>  even if there is no selection - the default action is to do  
> nothing"  - this is a rather silly gotcha.. It would be more  
> user/dev-friendly  if setData() or other manipulation automatically  
> prevented the  default action of copy..

As this is already implemented I don't think we can change it although  
I'd like to.

> * Consider if more MIME types need to be "mandatory", resolve the   
> other issues noted in the spec.

Issues resolved or postphoned.
-Hallvord

Received on Monday, 11 March 2013 15:35:00 UTC