Re: [editing] What browser internals can be exposed to help us move the caret in (and against) the block direction? (#56)

To avoid too big OT here, I posted #71.

But let me answer few things here:

>  your boss @fredck came up with the idea to leave the typing module for now and instead just have this very basic intentions spec and later on add modules, including caret, typing and return (... ) Maybe this is something you guys want to discuss internally?

We may have different opinions – nothing wrong with that ;). Besides, knowing @fredck's attitude I think that he might be misunderstood. Intentions is one thing, but no default actions is another.

> I notice that Aloha Editor has implemented its own caret movement system. The Aloha editor doesn't use contentEditable, but selections. 

Aloha 2 is still in early alpha AFAICS. It does not work on touch devices at all and the implementation is incomplete. I presume that the reasons for that are exactly as I described in #71.

Besides, these are not the only problems caused by stopping using `cE=true` (which is pretty similar to `cE=events`). I wrote an article recently where [I described a lot more potential issues](https://medium.com/medium-eng/why-contenteditable-is-terrible-122d8a40e480). Unless the spec we will produce will deal with all these problems, it will be unusable and hence `cE=true` will still be the only choice.

> I also see that ProseMirror hardly uses any of contentEditable, but keeps it in because it helps with the caret movement.

AFAICS, ProseMirror follows the same way as we defined for CKEditor 5 – don't let the browser change your content without your control, but do not interrupt (unless you want to change something) when it's doing its (harmless) job such as handling selection, composition, a11y, etc. This is much saner approach than dropping everything.

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