Re: [editing] CommandEvent and contentEditable=minimal Explainer

I have been reading this and have a comment:

"Issue 11: We may not need contentEditable=minimal. The same thing can be
accomplished by listening for commands and calling preventDefault on all of

I think we need contentEditable=minimal even if it is theoretically
possible to listen to all commands and preventDefault on them.

Listening to all events and preventing their defaults has the following
- All CommandEvents and other things that can modify the state of the
contents in our cE actually do fire events.
- We are actually able to enumerate all events that could potentially
modify the state of our contentEditable.
- All of these events can be preventDefaulted.

Given the transient nature of specs, implementations, and bugs I have a
hard time believing that the theory that we can just listen to everything
and prevent defaults has merit in practice.

One can easily imagine that some features provided by the UA won't fire
events. Or, no need to imagine: just look at "undo" called from context

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.

In practice, if we are left with the burden of listening to all events and
preventing defaults we are left in very much the same situation we're
trying to get away from.

If cE=min were spec'd to be an editable surface that had everything (or
almost) off by default, including future features, then these kinds of
surprises wouldn't happen. As developers we'd much rather implement new
APIs when we feel we can, rather than having to scramble to preventDefault
on new features when they appear on our end-user's browsers one morning.

Thank-you for considering this.

- Oliver Forget

Received on Friday, 13 June 2014 00:07:57 UTC