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

> - scroll the page if necessary such that the caret is visible 

We can probably add a capability to reveal selection based on the current selection.

> - compute the next caret position the user expresses the intention to move one line up (the problem we started with)

This can be addressed by `Selection.modify` working on a "detached" selection or some object that mimics selection behavior.  You can then `Selection.clone` and modify that "detached selection" as needed to figure out where it would go in DOM position.

> - Create a multi user editor and show the current position of the carets of the other editor participants (correctly)

This should be done using DOM positions since each such user may have a different screen resolution as well as fonts and therefore text layout would be different.  If you're doing a custom text layout, then you'd know exactly where the caret is so that's a moot point.

> - Save the last position of the caret when closing a document and restore it (correctly) when opening the document again.

Again, this should be done via DOM positions since the next time the user opens a browser, the document may layout differently.  Mozilla, for example, shows the caret at a different location at a boundary of bidi level based on heuristics so values such as that may need to be stored as well.  Regardless, I don't think knowing the CSS rect of the caret would help you restore caret since we don't have any API to set selection based on a CSS rect.

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