Re: clipboard events

On Tue, 10 May 2011 05:34:17 +0900, Ian Hickson <ian@hixie.ch> wrote:

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

No problem, I know what you've been up to :-p

I'm re-ordering this reply a bit to get to the main questions first.


> 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.

I've tried adding something:

http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model

I'm however still not quite sure how to fit it into the event loop. The  
task source will usually be the user interaction task source (but might  
also be occurring due to a fully scripted execCommand() call in  
implementations that allow this). So, to sum up: the events might fire

* as the default action of a keypress event
* because of a script passing 'cut', 'copy' or 'paste' as an argument to  
execCommand()
* because of user selections from a menu or UI button that causes no  
preceeding event in the document or environment

How/where would you recommend I say something about event loops and task  
sources to cover all three cases?

As you see, the processing model is still full of Issues and Todos, the  
main problem(s) are probably what types we should mandate support for and  
what to do about other ones.. But there is a new section on processing  
HTML that might be a model for how other types should be handled,  
depending on what (and how much) processing they need.

>> 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?

What you're saying is that we should not use the "normal" event default  
action model in this case? IMO adding data from the script even though  
there is a selection and the default action would have been to copy it, is  
inconsistent with how events work otherwise.

Suggesting that we add the data from the script even if the default action  
is not cancelled when there is no selection (and thus basically no default  
action) would be even worse: we'd end up with scripts that work as  
intended only when the user didn't happen to select some text.

> 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.)

If there is a selection, should not cancelling copy prevent copying it? Or  
are you intentionally arguing against that because of the nuisance  
potential?

>> 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.

It now is in read-only mode for paste.

>> 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.

Probably, but excuse me for not volunteering to do so at this point ;-)

>> > 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.

AFAIK, something that is not explicitly marked as informative is normative  
- no? And given that we're relying on the DOM Events spec, saying that an  
event bubbles should be pretty well understood?

> 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. :-)

Fair point :-)

Started fleshing this out. I'll probably try not to spend time on spec  
editing more often than once a month or so, so I'll get back to this in  
June or July.

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Wednesday, 18 May 2011 06:23:37 UTC