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

On Wed, Aug 5, 2015 at 11:11 AM, Frederico Knabben <f.knabben@cksource.com>
wrote:

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

+1

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

+1


>
>  * 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.
>
> Well, there is the clipboard api which now references execCommand:
https://w3c.github.io/clipboard-apis/#integration-with-rich-text-editing-apis

It is only an editor's draft, but nevertheless, it is in implementations
already.


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

Yes and no.

I agree that neither of those should ever show up in an official W3C
recommendation.

But at the same time, the way the W3C draft system is beign used by the
browser makers is that they already go ahead and implement some early
editor draft specs whereas other aren't.

Consequently, editor drafts are oftentimes recognizes as being
authoritative. So just having an editor's draft of an execCommand spec out
there is oftentimes regarded as a sign that execCommand is still alive by
other spec editors, who may then go ahead and write more things on top of
execCommand and even be implemented in browsers.

This is what happened here: Aryeh's draft was out there, then our version.
The clipboard api people saw that and assumed it was a good idea to
continue building on top of execCommand. Hallvord and me had actually be in
contact with over the last few months and had done rough readings of
oneanother's specs, but because there was no fat sign on the execCommand
draft saying "please don't build more stuff on top of this" we only very
recently discovered that he assumed doing those things via execCommand as
the only option would be enough, whereas we assumed that execCommand was to
go away.


So my conclusion: You are probably right that we cannot technically
speaking deprecate something that never existed in an official
recommendation. At the same time, we need a wording that goes further than
"we don't have time to work on this right now". It should instead
communicate something like: "execCommand is considered harmful. Please do
not build more things on top of this without discussing it with the editing
taskforce first.".

>
>
> --
> 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> wrote:
>
> 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
>
>
> 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
>
>
>


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