Re: [clipboard] kill onbefore* events?

On Mon, Mar 7, 2016 at 12:49 PM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

>
> On Mon, Mar 7, 2016 at 3:52 PM, Hallvord Reiar Michaelsen Steen <
> hsteen@mozilla.com> wrote:
>
>>
>> On Mon, Mar 7, 2016 at 2:50 PM, Johannes Wilm <johannes@fiduswriter.org>
>> wrote:
>>
>>
> > At the beginning of this year, the browser makers except Mozilla had an
>> > informal meeting about editing, and from what I gather, they did not
>> know
>> > about this. So their proposals seems to include copy/paste in
>> beforeInput
>> > and they have proposed another attribute to hold rich text content to be
>> > used for dragging/pasting.
>>
>> Hm..? I don't know anything about this. No biggie, we'll figure this
>> out. What exactly do you mean by  "include copy/paste in beforeInput"
>> - that for example Ctrl-C according to their view should trigger not a
>> "copy" event but a "beforeInput" event?
>
>
> The way we currently have it is that any user initiated editing operation
> triggers a beforeInput event with an inputType attribute specifying exactly
> what type of change the user is asking for. For many operations this is is
> in practice another event in addition to an already existing event
> (keydown, etc.), but for actions there is no good event to listen to.
>
> An exception up to this point was pasting/cutting -- for those we thought
> we would only listen to the events you were working on in the clipboard API.
>
> Now what the browser makers seem to have counted on is that the
> beforeInput event is also triggered for cut and paste within both cE=true
> and the other types of contenteditable. It would be a beforeInput event
> with the inputType attribute set to "cut" or "paste".
>
> And it doesn't seem like such an awful idea to me. For someone creating an
> editor, it should in theory mean that they only have to listen to the
> beforeInput event and based on that do all the required actions.
>

Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will
receive a 'beforeinput' event just before any DOM update (with an option to
cancel it), and you'll also receive an 'input' event just after the DOM was
updated.  If you want to track all DOM updates, then you only need to
listen to these two events.

Other events could also be sent before/after the DOM is updated, but it's
better to avoid sending events around needlessly. FWIW, this is why
'keypress' was deprecated -- there's no need for it since its functionality
is covered by 'beforeinput'.

I don't know the details and subtleties of the cut and paste events, but it
would be great if they could coordinate with (or be folded into)
'beforeinput'. Especially since a 'beforeinput' event should be sent before
the cut/paste DOM update occurs in any case. But the issues with 'copy' and
the formatting commands that Johannes mentions would need to be addressed.