Re: on execCommand() and script-triggered copy/cut/paste

On Tue, Aug 4, 2015 at 5:06 PM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

> But now that I found out that y'all are doing precisely that, I found it
> was necessary to put a warning in the spec documents saying that this spec
> is likely going to be deprecated, so that noone gets the idea to build new
> features based on it.
>
> At the F2F we probably come up with a better wording that is more precise.
>

I think "deprecated" is the right word for the goal you're describing, I'm
just saying the goal itself is unrealistic and therefore pointless.

If I may quote Aryeh Gregor himself (I hope he doesn't mind..)
"it's true execCommand etc. will probably never be removable"  - from
https://github.com/w3c/clipboard-apis/issues/16#issuecomment-127568051


>
> (Your spec is (obviously) at an early stage - for example it describes a
>> deleteContent intention but doesn't explain how to pass the direction of
>> the delete action to the JS listener.)
>>
>
> Not true -- there are both deleteContentForward and deleteContentBackward
> that make that very clear.
>

Oh sorry, I must have missed them, but I was reading
http://w3c.github.io/editing/contentEditableIntentions.html where these are
not mentioned.


> We are currently trying to make sure that the first version of these specs
> will be able to handle everything we need to do in today's leading JS
> editors.
>

(I'm still worried you're simply moving the complexity of implementing
editing well from the UA implementors to the JS authors. Probably a natural
impulse since the UAs have done a poor job.)




> So that leaves "copy". As I understand your security model, you allow
> execCommand('copy') to add any text or HTML content to the clipboard even
> if this text is invisible to the user, as long as the execCommand was
>  called as part of a function that was called due to user action (such as
> clicking on a button).
>
> So if you want the browser to copy some content that the user is not to
> see, you can simply create a contentEditable=true element, fill it with the
> content to copy, select that content, call execCommand('copy'), then remove
> the contentEditable=true from the DOM. See this example:
> http://pastebin.com/fnVGa7wC
>

You don't need those DOM modifications - just listening to the 'copy' event
the execCommand() call triggers and call event.clipboardData.setData() or
event.clipboardData.items.add().

It is a bit hackish though..


> That is then needlessly complicated for no good reason. Instead, it should
> just be enough to have a function such as document.addToClipboard(content)
> that can take text/html as it's argument and that has a security check that
> only allows the execution of this function if it ultimately has been
> initialized due to user interaction.
>
> However, I can see that we may end up with a few more such functions in
> the future document.pasteFromClipboard(), etc., some of which we cannot
> even think of now. So in that case it may actually be a good idea to have a
> generic interface, similar to execCommand(X), just with a different name.
> The different name is important so that it will be easier to remove
> execCommand in the future.
>

Why is it so important to remove document.execCommand() - rather than just
saying "it's not possible to use most commands for contenteditable=intents
elements"?

-Hallvord