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

On Tue, Aug 4, 2015 at 4:22 PM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

> Hi,
> I've always assumed that the Clipboard API spec would/should integrate
> with document.execCommand() and use its "commands" to trigger scripted
> copying and cutting (and, if UAs implement relevant permissions, pasting).
> See
> http://www.whatcouldbewrong.com/articles/html5-clipboard-support/
> for a description.
>
> Now, since I filed https://github.com/w3c/editing/issues/61 I've been
> reminded that execCommand() is considered deprecated.
>

To be sure: there is as of yet no formal decision to mark it as deprecated.
But the discussion so far has shown that none of the browsers are
interested in making execCommand or cE=true follow a spec, as there is too
much legacy code out there that depends on the current, broken code, for
any such changes to be possible. Also, there seems to be no interest in
continuing to work based on execCommand, or to continue to write more on
the current spec draft (quite understandably given that UA already signaled
they won't implement it).

My idea had hitherto been to bring this up at the F2F and figure out an
exact wording to put on the execCommand and cE=true draft specs to make
sure that noone else continues to build new features on this.

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.


> Some thoughts:
> 1) I think "deprecated" is not a useful classification because I don't
> think execCommand() can ever be removed from UAs. It's in too wide use.
> Frankly, even if we in a couple of years have a fully developed "editing
> intentions" spec and in another year or two browser implementations and
> libraries using it, there will be millions and millions of sites that won't
> upgrade anytime soon. Quite a few of them never will.
>
>
Browsers will obviously need to wait quite a while before removing
execCommand. But even 5 or 10 years is a lot less than forever. I think we
need a word that means "please do not build any new functionality on top of
this, as this functionality will likely be removed at some point in the
future". To me the correct word is "deprecated", but I have no strong
feelings about what the right wording.


> (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. The one you mention should only be used when it
is neither. But yes, so far this specification has developed merely based
on discussions and not on implementations. 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.



> 2) With your proposal (contenteditable intentions) it seems you have no
> parts at all that will require the UA to do some work in response to a
> script - but if you want to handle the use case "have custom buttons for
> clipboard actions" you'll need some way to integrate with the UA.
>
> I suggest that rather than reinventing a way to send "commands", you
> un-deprecate execCommand() but deprecate individual commands for use with
> contenteditable = intents. (Sounds like you would deprecate all legacy
> commands but cut/copy/paste.)
>

I don't think this is a good idea. We actually need to take away "cut" as
well, as the JS should do all operations that are about changing the DOM.
And from your "paste" I understand that it should never be accessed by JS
code directly itself. So we won't be able to use that either.

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

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. Due to the history of execCommand, there is no
authoritative lists of all the commands it provides (just an unofficial
draft specification in our repositories). I can see the point with this,
but actually I think the clipboard stuff should just work with two
functions (copy and paste) and not be intertwined further with the editing
specs for no good reason.






> -Hallvord
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org