Re: [clipboard] kill onbefore* events?

On Thu, Mar 10, 2016 at 2:24 AM, Gary Kacmarcik (Кошмарчик) <
garykac@chromium.org> wrote:

> On Wed, Mar 9, 2016 at 3:40 PM, Hallvord Reiar Michaelsen Steen <
> hsteen@mozilla.com> wrote:
>
>>
>> On Wed, Mar 9, 2016 at 11:19 PM, Gary Kacmarcik (Кошмарчик)
>> <garykac@chromium.org> wrote:
>>
>> > There is a design tension between the 2 extreme approaches, each with
>> pros
>> > and cons:
>> >
>> > (1) A single 'beforeinput' event that fires for all "input" activities.
>> > Pros: Developers only need to support this and don't worry about the
>> > details. Basic support for new input types just work without additional
>> > work.
>>
>> I don't see how this logic holds if you add something like beforeInput
>> for paste. Suppose that I already wrote a beforeInput - based editor.
>> Suppose it's pretty good at handling the events I already know - I've
>> carefully implemented typing, deletion etc based on beforeInput
>> events. Now all of a sudden a modern browser is sending me beforeInput
>> with eventType set to "paste" and with an event.clipboardData property
>> I'd have to pull data from to insert into the DOM to make the paste
>> work. How is that something that will "just work" in my app? It
>> clearly won't.
>
>
> Unless the `beforeinput` event is canceled, the DOM will be updated
> without any special handling.
>

Gary is thinking of the usecase where the beforeinput event is used in
cE=true, it seems. Hallvord was possibly thinking of cE=intentions/events?


> Most webapps don't need to do anything to support typing, deletion, et al,
> and they wouldn't need to do anything to support paste.
>

Ok, as for that last sentence "Most webapps don't need to do anything to
support typing, deletion, et al, and they wouldn't need to do anything to
support paste." I think our experiences wit that are vastly different, and
I was actually wondering if the Gmail or Microsoft Office 365 developers
would have any opinion about that.

In my experience, I kind of need to override almost everything, or at least
make checks about where the caret is before something is changed before I
decide to let the browser handle it.

At any rate, our differences in experience doesn't seem to mean that we
reach different conclusions.

Having the editor do something new, such as "voice input" all by itself is
not something I would think work either.

But that's precisely why the beforeinput event would come in handy: Say a
user uses version 4.35 of my editor from spring 2017. It supports all the
known beforeinput events at that time.

Three months later, Apple announces the immediate availability of a new
version of Safari with an unstandardized "voice input" eventType, while I
am off scuba diving for 6 weeks.

Once I get back to work, I will start to program a version 5.0 of my editor
that handles the new eventtype correctly.

Anyone still not having upgraded from version 4.35, the editor doesn't end
up doing crazy/uncontrolled stuff when receiving voice input. It simply
does nothing on voice input because the switch statement has no
case-definition for it and I made sure that any unknown eventType results
in no changes to the DOM.

And that's good. I can go scuba dive without having to panic. The
alternative is that I would have to constantly watch out whether there are
new ways of inputting things, and if so, cancel my holiday, do 24 hour
shifts and update my editor really quickly to listen and handle the new
event, and pressure all site administrators into updating their
installations really fast. Sounds like a nightmare.


> A rich editing app may need/choose to do extra work, but pasting into a
> regular <input type="text"> should work without any extra effort.
>
> Consider `beforeinput` (as it replaces `keypress`):
> * `beforeinput` event is sent with key info. If I ignore it, the DOM will
> be updated with the key value, if I cancel it, it doesn't. If the
> programmer does nothing, key presses just work.
>
> Now a paste action happens:
> * `beforeinput` event is sent with the paste data (just in case the app
> wants to do something with it). If ignored, the DOM will be updated, If
> canceled, the DOM won't be updated. If the programmer does nothing, pasting
> just works.
>
> Now a brand-new-event-that-updates-the-DOM is sent:
> * Same thing. `beforeinput` event is sent. DOM is updated (or not, if
> canceled). It just works.
>
> In fact, that's pretty much how the Clipboard API spec says the 'paste'
> event should work:
>
> 7.1.3 The paste action
>
> If the cursor is in an editable element, the paste action will insert
>> clipboard data in the most suitable format (if any) supported for the given
>> context.
>
>
> This means that it updates the DOM, which means that a `beforeinput` event
> needs to fire.  And if we're firing a cancelable `beforeinput` event, then
> there's no point also sending a `paste` event that does basically the
> thing. This is the exact same situation that we had with `keypress` and it
> was deprecated in favor of `beforeinput`.
>
>


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