On division between different specs (was: Re: on execCommand() and script-triggered copy/cut/paste)

On Thu, Aug 6, 2015 at 7:41 AM, Yoshifumi Inoue <yosin@google.com> wrote:

> From who working on editing code in browser, can we have copy/cut/paste as
> method in Selection? And describe, what HTML and plain text copied into
> clipboard, what to delete, and how paste works? at least, copied content is
> welcome and helpful for browser maker.
>

I don't think moving parts of execCommand to the Selection API is a good
idea as the Selection API doesn't really deal with changing the DOM, as far
as I can tell.


At the same time, I can see the point that one just wants to copy the
current selection, also when the current selection is not in a
contentEditable container. execCommand doesn't/shouldn't work outside of
contentEditable, so a new method would be needed for that.

There are of course many ways of doing it, but one possible solution is to
divide it like this:

*Clipboard API*: Defines general methods A and B for adding and removing
items from the clipboard that includes checking that it has been called
from a trustworthy source. It also defines how methods A and B can be
called directly from JavaScript.

*execCommand*: Defines copy and cut and how they call method A from the
clipboard API. For cut it also needs to define exactly how things are
merged together when content is removed. It also defines paste and how it
called method B from the clipboard API. Also here it needs to define
exactly how things are merged together.

*Selection API*: Defines a method C that calls method A with the contents
of a selection as argument.

The most complex of these is the execCommand part. Currently we have some
text there to ensure the security that I tried to adjust so it matches the
text found in the Selection API, but a lot more complex will be the merging
of different types of content that I don't think has been defined so far.

This division would then also allow for a future contentEditable module
under the new modular structure to hook into this.



>
> It seems spec'ing execCommand takes long time, but Selection, or just
> spec'ing copy/cut/paste, seems to be shorter and easier than execCommand
> spec.
>

Browser makers hitherto have had no problem to implement execCommand
without any spec at all and implementing a version of the clipboard api
spec in editor draft level, so I don't see why they should have a problem
implementing parts of a specification draft of execCommand.

As Ryosuke writes: "And I can assure you can’t build a Web browser
compatible with the Web without contenteditable=true and execCommand
support." And that is of course equally true for all execCommand actions,
not just a few of them.




>
> My motivation here is interoperability, Chrome/WebKit put special markup,
> such as class="apple-interchanged-newline", but not others. And, it is hard
> to keep appearance paste from Word/Excel into browser.
>
>
Yes, I understand. We all want that and that's why it would be good to have
such a mechanism.



> -yosi
>
>
> 2015年8月6日(木) 14:01 Johannes Wilm <johannes@fiduswriter.org>:
>
>>
>>
>> On Thu, Aug 6, 2015 at 5:50 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> ...
>>
>>
>>> No, execCommand **definitely** needs to remain in the recommended spec
>>> as an obsolete feature regardless of whether its use is discouraged or not.
>>>
>>> The idea that we should only write specifications for the bright new
>>> future has failed. See XHTML 2.0. We need to spec every obsolete feature
>>> that is needed for Web compatibility reasons because that’s the only way we
>>> can allow people to write new interoperable browser from scratch. And I can
>>> assure you can’t build a Web browser compatible with the Web without
>>> contenteditable=true and execCommand support. A whole bunch of contents
>>> e.g. Gmail would not work.
>>>
>>>
>> I think there is some misunderstanding here. No information is lost.
>> Everything about the clipboard api and execCommand is still specced. It's
>> just that those commands relating to the clipboard are defined in the
>> execCommand spec draft, just as all other execCommand based commands.
>> Hallvord can also be added as an editor to the execCommand spec and then he
>> can just change that section in whatever way is needed, whenever it is
>> needed.
>>
>>
>>
>> --
>> Johannes Wilm
>> Fidus Writer
>> http://www.fiduswriter.org
>>
>


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