Re: clipboard events

(Sorry for the long delay in responding to this.)

On Wed, 26 Jan 2011, Hallvord R. M. Steen wrote:
> On Fri, 24 Dec 2010 07:21:35 +0900, Paul Libbrecht <> wrote:
> > - this seems to support the insertion in the clipboard's data of other 
> > types than what is currently commonly supported by browsers and the 
> > minimum quoted there; this is good and important. I think, for 
> > example, that such data as the iCal format would fit very well and be 
> > very useful here.
> It intends to, but this has two open issues: * I assume that many OS 
> clipboard implementations have an enumerated list of "known" formats, 
> I'm not sure if all OSes can handle a request to push "text/foobar" data 
> to the clipboard. Does anyone know if we can rely on such functionality 
> being truly cross-platform?
> * There is not yet a clear way to push multi-part or alternate formats 
> to the OS clipboard from JS. To use something like iCal, I guess best 
> practise would be to push one human-readable text/plain string for 
> target software without iCal support, and one alternate entry in iCal 
> format. I guess that can be done with
> DataTransferItem add(in DOMString data, in DOMString type);
> I.e. spec for copy event would be
> * default action: copy any document selection
> * if default action is prevented: push data in drag data store (as 
> manipulated by setData() or items.add()) to clipboard, probably mapping 
> certain known values to native clipboard formats while doing so.
> Ian - would that make sense?

I think you'd want to push the script-added data regardless of whether the 
event is canceled or not. Why would the script add the data otherwise?

I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' 
event, ideally so much so that you can literally use the same function for 
both. (Canceling 'cut' would prevent the default deletion of the 
selection, canceling 'copy' has no effect.)

> However, what about items.add() called during a paste event listener?
> Currently I do not allow paste event listeners to update the clipboard with
> setData(), it seems strange. Should we just disallow this too?

I'd model 'paste' on 'drop', including having the drag data store in 
read-only mode, yes.

> On Fri, 07 Jan 2011 04:31:01 +0900, Ian Hickson <> wrote:
> > Is it intended to also cover cut, copy and paste? The current spec 
> > draft seems very vague about when the events fire and what their 
> > default actions are, but I can't tell if that's intentional or not.
> Better now?

Not really. There's no processing model. IMHO we need a list of steps 
somewhere that defines how the events fire with respect to the event loop, 
which task source is used, what mode the drag data store is in, what the 
default actions are, how they interact with mutation events, etc.

Basically, the cut/copy/paste equivalent of:

> On Sat, 08 Jan 2011 05:02:02 +0900, Ian Hickson <> wrote:
> > > > Is it intended to also cover cut, copy and paste?
> > > 
> > > Sorry, I don't understand the question.
> > 
> > Well, for example, the 'cut' operation involves removing or mutating DOM
> > nodes (for contentEditable) or editing the control value (for <input>) or
> > raw value (for <textarea>), and modifying the selection accordingly.
> The timing is in scope, how to do the actual modifications is not (i.e. 
> I'm not trying to decide how the implementation should figure out what 
> DOM nodes to remove when the user selects something and cuts.)

We probably should define that.

> > Sure. For example, when should the paste event fire relative to when 
> > keydown/keyup events fire? When should the paste event fire relative 
> > to when the 'input' event fires?
> Fixed.

Not really. It says it's asynchronous, but what event source should it 
use? Should it be queued on the event loop, or should it fire at some 
other step? Should it fire as part of the same task that mutates the DOM? 
Should it fire as part of the same task that fires the keydown event, or 
some different task? This would define, e.g., the relative order of tasks 
queued during handlers of the keydown event and those queued during the 
cut/copy/paste events.

> > Where do these events fire relative to mutation events, for 
> > contentEditable? What should the default action of 'paste' be, in 
> > terms of DOM mutations when the cursor is in a contentEditable 
> > section?
> It is fixed to the extent that I consider these things in scope.. I'm 
> trying to keep this spec short and sweet :)

I think it'd be better to keep it precise. :-)

> > Assuming RFC2119 semantics, the spec is lacking detail. For example, 
> > nothing normatively says whether the events bubble or not, it's just 
> > left up to the reader to assume that the table implies that it does.
> I've tried to sharpen the use of "must", "must not" and the like. I'm 
> not entirely sure why 'Bubbles: yes' in a table isn't normative or 
> explicit enough though.

Nothing seems to define whether those tables are normative or informative 
or what they mean if they're normative. (This is a problem common to many 
DOM specs. They are written in a very poor style. I recommend following 
more the style of Anne's DOM Core spec.)

> > since that's the main driver for changes to the DataTransfer 
> > interface. I'm happy to work with you to make sure the DataTransfer 
> > spec still works for copy/paste.
> It should sort of work, but I'm not sure what to do about the somewhat 
> different terminology used. For example, the DnD spec talks about the 
> "drag data store" a lot. Should we just say that for the purpose of the 
> CCnP spec, the "drag data store" IS the OS clipboard, or an 
> implementation-specific representation of it?

The drag data store is a UA-specific concept that is just used to define 
the processing model. You'd want to define how and when it is transferred 
to and from the system clipboard.

> Does the CCnP spec need to say explicitly how to expose OS clipboard 
> content as a "drag data store"?

It needs to say everything explicitly. It's a spec. :-)

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 9 May 2011 20:35:09 UTC