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

I’m afraid that we need to simplify and summarise this talk a bit.  


## Point 1: Yes, developers want to execute copy and paste by code. For example with an UI button that triggers the action.

 * It is unfortunate that execCommand(“cut/copy/paste”) is seen as the way to do it. It is just like execCommand(“bold”) and others and therefore it should not be used.

 * The one and only right way to handle copy and paste programmatically is to have an API to set the clipboard data and to retrieve it (whenever security settings allow for it).That’s where our focus should be.


## Point 2: Deprecating execCommand and (maybe) cE=true

 * There is no interest for browsers to remove support for execCommand and cE=true. It makes sense, for the 10 years to come at least.

 * There was a lot of effort put on trying to spec these features and there would be still 10 times more work to make it right. Even though, there will be no interest from browsers to follow such specs, especially taking in consideration cE=events and the new modular approach we have for it. Therefore, spec’ing it is a waste of time and energy.

 * AFAIK, there is no W3C “recommendation" that includes execCommand and contenteditable. Therefore, in the specs point of view, there is nothing to “deprecate” because these features don't exist.

 * Therefore my option is to simply non-spec cE=true and execCommand. In other words, stripping them out of the current HTML5 WD.  


--
Frederico Knabben
CKEditor Project Lead and CKSource Owner



On Wednesday 5 August 2015 at 08:51, Johannes Wilm wrote:

>  
>  
> On Tue, Aug 4, 2015 at 11:06 PM, Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com (mailto:hsteen@mozilla.com)> wrote:
> > On Tue, Aug 4, 2015 at 5:06 PM, Johannes Wilm <johannes@fiduswriter.org (mailto: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
>  
> That sounds like a defeatist attitude. In that case I think the word "deprecated" is correct. Not everything that is marked as "deprecated" disappears quite as fast as those deprecating it had hoped for. Sometimes things are even "un-deprecated". But to give up before one even begins doesn't sound like a healthy attitude.
>  
> Also, I do not think that people in 200 years time will keep execCommand around because someone wrote a webpage in 2007 using it and refuses to change it now.
>   
> >  
> >   
> > >  
> > > > (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.
>  
> Ah, I see. Yes that needs to be changed there. The current list of intentions is in this spec:
>  
> https://w3c.github.io/editing/input-events.html
>  
> But what is missing there are intentions related to the clipboard (paste/copy/cut) as we had thought we could work with those defined in the clipoboard api. But let us know if you think we should create them here separately.
>   
> >   
> > > 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.)
>  
> Yes, the very first step is about giving access to the primitives necessary to create an editor on top in JS. Already today most JS editors have to reimplement most of the logic as browsers are so inconsistent and broken.  
>  
> But the idea is for this to only be the first module in a series of modules. Once we have this, and have some implementations of it, building on top of the principles laid down in the Extensible Web Manifesto https://extensiblewebmanifesto.org/ it should be much easier to create specs for particular sub areas (typing, paragraph splitting, caret movement, etc.) by JS polyfilling and testing on real users.
>   
> >   
> >  
> >  
> > >  
> > > 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().
> >  
>  
> I tried doing the same without adding the contentEditable attribute, and it wouldn't work. Am I missing somethign here?  
>   
> > It is a bit hackish though..
> >   
>  
> Right, so let's not start doing hackish things.
>   
> > > 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"?
>  
>  
> To have a clean break from a broken past. And also to make the web less hackish. If I understand you correctly, and Chrome is currently behaving correctly in terms of security, the rule is that: We allow the browser to put arbitrary content into the clipboard, as long as:
>  
> A) the script that does it is directly triggered by the end user
> B) the script is willing to go through some loops by creating a contenteditable element, putting the contents in there, copying it, and removing the contenteditable element again.
>  
>  
> A makes sense, but B just seems nonsensical. Anyone wanting to put "bad" content onto the clipboard will easily be able to do it, whereas anyone else who just wants to put legitimate content into the clipboard will have to jump through a meaningless series of  DOM changes.
>   
>  
> If I understand you correctly, you want us to use execCommand just for the single case that one wants to create an extra UI button for copying. Buttons for pasting will not work anyway, and the cut button would in the end also call the same execCommand('copy',...)
>  
>  
> I don't think it's worth it to keep execCommand around for that.
>  
> But possibly we could have a function to declare an intention. Such as cEelement.execIntention('copy') or cEelement.execIntention('paste').
>  
> That could possibly be used then to also declare other intentions by custom UI buttons.
>  
> Alternatively y'all put something similar into your clipboard api.
>  
> --  
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org (http://www.fiduswriter.org/)
>  
>  
>  
>  
>  
>