That seems wrong.

execCommand() executes actions. For copy/cut/paste at least those actions are defined in clipops. Those actions dispatch the events and might do something depending on whether or not the canceled flag is set for those events.

That is the layering and from that perspective execCommand() seems fine. However, it should perhaps be rewritten in such a way that it runs the same set of steps for all actions, rather than interweaving the various types in this manner.

(In reply to Anne from comment #1)
> That seems wrong.

As in "the wrong way to do things from a web platform technology perspective" or as in "the wrong way to organise specs"?

> execCommand() executes actions. For copy/cut/paste at least those actions
> are defined in clipops.

Currently - no. The clipboard API spec is not defining any "actions" - merely defining what events should be dispatched when such actions are triggered. Should it define "actions" that the commands in the editing spec should trigger?

> Those actions dispatch the events and might do
> something depending on whether or not the canceled flag is set for those
> events.
> 
> That is the layering and from that perspective execCommand() seems fine.

If that's the layering, it sounds like the text about execCommand() should not say anything about events at all.. (but maybe that was the intention behind adding that note?) The spec defines copy/cut/paste commands, for example:
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-copy-command
but this says nothing about events.

> However, it should perhaps be rewritten in such a way that it runs the same
> set of steps for all actions, rather than interweaving the various types in
> this manner.

Of course it doesn't matter much where we define things as long as they are well defined.

(In reply to Hallvord R. M. Steen from comment #2)
> As in "the wrong way to do things from a web platform technology
> perspective" or as in "the wrong way to organise specs"?

The wrong way to do things. There should be one cut/copy/paste operation. And that operation should be responsible for dispatching events and handling the canceled flag after dispatching.


> Currently - no. The clipboard API spec is not defining any "actions" -
> merely defining what events should be dispatched when such actions are
> triggered. Should it define "actions" that the commands in the editing spec
> should trigger?

Yes. And it does define actions, since it defines dispatching events and then handling the canceled flag on those events. That by itself is bigger than just dispatching events and therefore it defines actions.

I have a difficult time digesting what's exactly being proposed here, but if I understand correctly, I think I agree with what Anne is suggesting.  Specifically, I think execCommand("copy") for example, if permitted to run, should do the exact same thing as Ctrl+C does, which includes firing the event and accepting the content to be copied to be modified along the way.

We should also spec the circumstances under which these commands are allowed to be executed from script.  I think we need to disallow paste unless it's being initiated by a trusted UI provided by the UA, and disallow cut and copy unless run in response to a user initiated event.

(In reply to Ehsan Akhgari [:ehsan] from comment #4)
> I have a difficult time digesting what's exactly being proposed here

It seems basically the disagreement is just about WHICH spec covers what - in other words, should the Editing spec say that document.execCommand('copy') fires a copy event, or should the Clipboard API spec say that? 

I expected the Editing spec to say this (since from my point of view it defines "execCommand()" and its "commands") whereas it seems Anne and Aryeh say this should be stated in the Clipboard API spec, since it should define the "action" for "copy", which the editing spec and its "copy" command should just reference. Fair enough as long as I understand how I should define an "action" that the Editing spec can refer to. Maybe Anne can tell me :)

(So this bug is probably either invalid or should be moved to Clipboard API if I need to fix something to have these "actions" clearly defined.)

> Specifically, I think execCommand("copy") for example, if permitted to run,
> should do the exact same thing as Ctrl+C does, which includes firing the
> event and accepting the content to be copied to be modified along the way.

Agree.

> We should also spec the circumstances under which these commands are allowed
> to be executed from script.  I think we need to disallow paste unless it's
> being initiated by a trusted UI provided by the UA, and disallow cut and
> copy unless run in response to a user initiated event.

And this is already handled by the Clipboard API spec :)

(In reply to Hallvord R. M. Steen from comment #5)
>> Specifically, I think execCommand("copy") for example, if permitted to run,
>> should do the exact same thing as Ctrl+C does, which includes firing the
>> event and accepting the content to be copied to be modified along the way.
> 
> Agree.

If you agree with that, and that operation is defined in clipops, what is unclear? At a basic level, such an action is just this:

1. Details of copy operation...
2. Prepare /event/ to notify listeners.
3. Dispatch /event/ to listeners.
4. If /event/'s canceled flag is set, terminate these steps.
5. More details of the copy operation.

> If you agree with that, and that operation is defined in clipops, what is
> unclear?

The only remaining question is whether my spec has the right "hooks" and terminology when defining those actions.

That's moot, because the editing spec is dead, so it won't hook into your spec anyway.  :)

Spec has been rewritten per the model this bug suggested