Re: [editing] CommandEvent and contentEditable=minimal Explainer

I certainly understand the concern that it would be impossible to properly
catch and cancel all events.  But I think that is somewhat the point - it
forces browser vendors to get these parts right.  All changes to an
editable dom must fire an event before the modifications are made, and must
be cancelable. Further, I'd say that if the number of events you would need
to preventDefault on grows larger than selection, command, and maybe
clipboard then that implies that we are not building the right APIs.


On Sun, Jun 15, 2014 at 11:49 AM, Piotr Koszuliński <
p.koszulinski@cksource.com> wrote:

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