Re: [editing] CommandEvent and contentEditable=minimal Explainer

On Sun, Jun 15, 2014 at 5:15 AM, Olivier F <teleclimber@gmail.com> wrote:

>
> 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.
>
>
I've got very similar feelings about all this. For years features have been
randomly added to contentEditable=true and structuring them now seems for
me as undoable. As I commented in [1] and [2] there are features related to
contentEditable that do not fit in the CommandEvent and CommandQuery
proposals very well. We agree that undo, clipboard and drag and drop
interfaces have to be separated from commands. Why not other? Why all other
features have to be pushed into "commands" section?

If the commands' related APIs (I do not include very useful low level user
intent events into that) and commands themselves will lack precision, then
the only use that a cross-browser editor could make of them will be to
disable everything. And we'll need to hope that we haven't disabled too
much (e.g. clipboard events) or too few things, because imprecise spec will
not clarify this.

Less is better. Give us stable platform and we'll build great solutions on
top of that. Make the platform unpredictable and we'll be fighting it the
rest of our days.


[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0876.html



-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer