Re: [clipboard] kill onbefore* events?

On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик) <
garykac@chromium.org> wrote:

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

Correct - two rather than one. I was thinking of a European-language text
editor that would handle every possible editor operation itself. it would
only need to listen to the beforeinput event. An editor using IME or
letting the browser take care of part of the editing operations will also
need to listen to the input event.  At any rate, it's not more than 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.
>

To me this sounds good. But maybe the clipboard api people have objections?


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