Re: [editing] CommandEvent and contentEditable=minimal Explainer

On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

> On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >> On Jun 12, 2014, at 5:07 PM, Olivier F <teleclimber@gmail.com> wrote:
>
> >> Imagine as well a situation where a UA creates a new way to paste
> content, and to prevent confusion with "paste" they decide to create a new
> ua-prefixed event "uaMagicPaste". Now our end-users have a  way of pasting
> content into our editor's DOM without any intervention at all on our end,
> resulting in breakage and bugs.
>
> This is a good point. Registering for and calling preventDefault() on
> CommandEvent and BeforeSelectionChangeEvent will catch all new events in
> those categories, but ClipboardEvents must be listened to individually
> (Cut, Copy, Paste). We should consider whether we disallow new
> ClipboardEvent types or allow a generic ClipboardEvent listener, which
> would catch uaMagicPaste. I'll add a note to the Explainer for this.
>

Yes, we could add ClipboardEvents and funnel all clipboard events through
there, that would work.

But I also noticed that Issue 3 was added: "Do we need DragEvents too". And
yes we do, good catch! It is totally possible to alter the DOM of a
contentEditable by dragging something on top of it.

I guess we can add DragEvents, but to me this illustrates why the practice
of enumerating and capturing all current and future events to
preventDefault them is not the right approach.

For enumerate+preventDefault to work, every possible event that could
change the cE's DOM has to fire correctly and cancel correctly. Every one.

I can't help but to feel that there will always be something missing.
Something we didn't think of in the spec, something the UA forgot to
implement, some bug that prevents the event from being fully canceled, or
some brand new interaction paradigm with its own event Class. Just one of
these in effect in one major UA and editor devs all over are in pain.

So long as enumerate+preventDefault is the only way for editor devs to
control their editors, I'm concerned that there will be a constant source
of difficulty trying to work around the "leaks" in the spec/ua/future, and
that the end-user experience will continue to suffer as a result.