We should keep data in UI events for beforeInput that does the text/plain serialization. We should add dataTransfer to the editing spec for other mime types(html, text with line breaks, etc)

[gked]

No description provided.

[johanneswilm]

Under what circumstances will we have richtext content? Is this for dragging/dropping? So far we don't have a beforeInput event for pasting.

[gked]

These are basically undo/redo/copy/paste user input types and we should be able to handle cases when there is rich text invlolved.

[johanneswilm]

@gked: The dataTransfer attribute for dragging usually depends on the setData method to specify what the piece of data that is to be dragged is to be. From you description of it, it sounds as if the dataTransfer attribute it to be a DataTransfer instance with the html version of the data already set (doing something like setData('text/html', element.outerHTML) ).

[johanneswilm]

@hallvors I have been testing quite a bit and read through all I could find about the selection API and dataTransfer.

Please let me know if you agree with the following assessment:

1. The cut/copy events of the clipboard API are in a sense beforeinput events as they should (if implemented correctly) allow for the script author to change the content of what is being copied before it actually hits the clipboard (in the case of copy and cut).
2. Paste can also be influenced, but not by using setData. Instead, one has to prevent the event and handle the paste manually.

Correct?

It seems there are two main directions we could go:

1. Make beforeinput(inputtype:'copy') be another way of listening to the copy event (is this even possible/common practice?). The advantage of this would be to only have to listen to the beforeinput event. Also, whatever functionality we come up with to limit context menus, etc., may be easier to make work this way.
2. Keep all the clipboard events separate from the beforeinput events. Advantage is that we don't need to touch the clipboard API very much.