Create separate plugin for contentEditable=false

[Alfonso Martínez de Lizarrondo]

In order to support correctly contentEditable=false there are a number of additions to the normal code and that means a general performance hit that should required only for those systems where such non-editable elements are being used.

By moving some functions to a separate plugin we can avoid most of the performance hit as well as allowing to keep improving such support without a degradation for the rest of uses.

[Alfonso Martínez de Lizarrondo]

Proposed plugin

[Garry Yao]

The skeleton implementation need to at least handle the per element case, on which some of current (core) plugin relied on, like 'form' plugin.

[Alfonso Martínez de Lizarrondo]

If it needs to handle at least the per element case, I think that it might be better to leave it as is, and put in the plugin only the changes of the wysiwygarea plugin.

Does that sound right?

[Piotrek Koszuliński]

I think that the performance hit is inevitable. Especially now, in 4.3, where we had to add code to selection system, styles system and few other places. Separating that code would be hard and would result in situation in which we would have to test two editors. Performance is important, but stability and maintainability have higher priority.

[Alfonso Martínez de Lizarrondo]

This was a proposal three years ago to start implementing enhanced contentEditable functionality without affecting the rest of the system.

Of course that doesn't make any sense right now.

[Piotrek Koszuliński]

I know :D But I felt that I need to explain my decision.