Re: [editing] Should cE=events (or cE=whatever now) handle selection? (#71)

If I understand correctly, the goal of this exercise is to gut out most of the complexity from contentEditable, while still allowing JavaScript components to implement rich text editors.

I think what both CKEditor and ProseMirror (and CodeMirror on mobile, to a certain extent) are doing (leave selection to browser, but intercept editing actions) illustrates the way forward pretty clearly. Those could basically keep working the way they work now, just switching to a different contentEditable mode, and handling some new events.

Removing the cursor/selection entirely would be a disaster, I expect. You can implement proper cursor motion using just existing APIs, but it is a big, complicated problem (bidi text is hard to reason about). People wouldn't bother. You _can't_, as far as I can see, allow people to manipulate selection and place the cursor on touch platforms without having the browser be aware of the selection. (This is why CodeMirror, which has most of this stuff already implemented, does enable contentEditable on such platforms.) The same, by the way, goes for screen readers -- those get lost easily if the selection isn't managed by the user agent.

So a good start would be to leave selection, focus, and cursor display in scope for the new contentEditable approach, but entirely disable built-in editing, filling the gaps that leaves (IME input, spell correction, ...) with better events. That would be all I'd need to make CodeMirror and ProseMirror work.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/71#issuecomment-132174931