Re: existing contenteditable spec

On Thursday 28 May 2015 at 13:23, Aryeh Gregor wrote:
> One important question to ask is: do editing libraries not want to use
> contentEditableTrue because it doesn't serve their needs at all? Or
> because it's not presently interoperable? If it's mainly the latter,
> then the best way forward is probably to work on interop of
> contentEditableTrue and allow scripts to hook into it. Only if the
> libraries really want to rewrite everything that all keystrokes do
> does it make sense to have a whole separate system (and maybe not even
> then).

I think you summarised it well. To make cE=true usable, we need the following:  

 1. Quality behavior spec’ed.
 2. Interoperability
 3. Hooks for overriding the behavior.

One of the ideas that made cE=typing was that cE should be “modular”. It means that “typing” was one of the modules but we could have others. In this way one could have contenteditable=“typing newline delete etc”, enabling a series of editing modules. Each module could be spec’ed independently. Finally, cE=true could be simply spec’ed as a shortcut to have all modules enabled.

I’m for spec'ing cE=true to make it useful and I like the modularization idea.