RE: clipboard events

>
> Clipboard API and events
>
> Status of this document
>
> This is a Clipboard API event specification draft edited by Hallvord R. M.
> Steen, Opera Software. Although I've used W3C stylesheets for convenience
> this spec is not currently adopted by the W3C.
>
Thanks for taking initiative on this topic.  I'd love to see some spec on
this area.  I'm mainly concerned about the backward compatibility with
Internet Explorer's implementation but as soon as the following problems are
addressed, I'd like to bring it up on the WebKit community.

If the cursor is in an editable element, the default action is to insert
> clipboard data in the most suitable format supported for the given context.
>
> In an editable context, the paste event's target property refers to the
> element that contains the start of the selection. In a non-editable
> document, the event is targeted at a node focused by clicking or by an
> interactive cursor. If the node that has focus is not a text node, the event
> is targeted at the BODY element.
>
I'm not sure if it makes sense for the element to be the start of selection.
 Why not just pass the root editable element?  The website already have
access to the selection so it can get start/end of selection.  Mentioning of
clicking or cursor is unnecessary.  One can use keyboard to move focus /
selection and copy / paste should still work.  I'm not sure why we're
special-casing text node / non-text node.  Is there some reason to this?
 (i.e. compatibility with Internet Explorer?)

 TypepasteInterfaceClipboardEvent<http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#clipboardevent>
> CancelableYesBubblesYesTargetElement
> Interface ClipboardData
>
> How should we define the relationship to the HTML5 DataTransfer<http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-datatransfer-interface> interface?
> Can DataTransfer inherit from ClipboardData and add the drag-and-drop stuff,
> or should we just defer to HTML5 for all of this?
>
I don't think we need to inherit one another as long as either one spec
refers to the other's.  What I don't want to see is two duplicated spec one
for DataTransfer and one for ClipboardData.  Ideally, it's backward
compatible with
http://msdn.microsoft.com/en-us/library/ms535220(v=vs.85).aspx but I guess
getData and setData's return type prevent this.

IDL definition
>
> interface ClipboardData {
>     void clearData <http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#clipboarddata-cleardata>( in optional DOMString type );
>     DOMString getData <http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#clipboarddata-getdata>(in DOMString type);
>     void setData <http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#clipboarddata-setdata>(in DOMString type, in DOMString data);
>     DOMStringList types <http://www.mail-archive.com/public-webapps@w3.org/clipboarddata-types>;
> }
>
> I would differ definitions of all methods to HTML5's dataTransfer.

 Clipboard event interfaceIDL definition
>
> interface ClipboardEvent : Event <http://www.w3.org/TR/DOM-Level-3-Events/#events-Events-Event> {
>   readonly attribute ClipboardData <http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#clipboarddata> clipboardData;
>   void initClipboardEvent <http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#clipboardevent-initclipboardevent>( in DOMString eventType,
> 		in boolean canBubble,
> 		in boolean cancelable,
> 		in DOMString dataType,
> 		in DOMString data );
> };
>
> The ClipboardEvent interface extends the Event interface. [DOMEVENTS<http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#refsDOMEVENTS>
> ]
> Attributes clipboardData
>
> The clipboardData attribute is an instance of the ClipboardData<http://www.mail-archive.com/public-webapps@w3.org/msg11532.html#clipboarddata> interface
> which lets a script read and manipulate values on the system clipboard
> during user-initiated copy, cut and paste operations.
>
I'm not sure if we want this.  Internet Explorer already implements most of
this spec but ClipboardData is implemented as a property of window object.
 Why deviate?  Of course, there's concurrency issue associated with
clipboard (i.e. content can change between the time website calls two
methods on clipboardData).  Are there other compelling reason not to be
compatible with Internet Explorer?

 Integration with rich text editing APIs
>
> If an implementation supports the document.execCommand method and allows
> calling it with the commands "cut", "copy" and "paste", the implementation
> must fire the corresponding events. The event is syncronous and may prevent
> the execCommand() call from having its normal effect.
>
Sounds good to me.


>  Privacy concerns
>
> Untrusted scripts should not get uncontrolled access to a user's clipboard
> data. This specification assumes that granting access to the current
> clipboard data when a user explicitly initiates a paste operation from the
> UA's trusted chrome is acceptable. However, implementors must proceed
> carefully, and as a minimum implement the precautions below:
>
>    - Objects implementing the ClipboardData interface must only be
>    available within the ClipboardEvent event handler.
>
>
>    - If a script stores a reference to an object implementing the
>    ClipboardData interface to use from outside the ClipboardEvent event
>    handler, all methods must be no-ops when called outside the expected context
>    - Implementations must not let scripts create synthetic clipboard
>    events to get access to real clipboard data
>
> This sounds quite reasonable things to do but I'm not sure if we should
spec it.  Vendors can decide what to do by themselves.  For example, I'd
imagine browsers can implement some interactive UI that lets user decide
whether or not he/she wants to paste / copy certain content on demand.
 Allowing access only within the event handler might be too restrictive.

Best regards,
Ryosuke Niwa