Re: [editing] ContentEditable with UserSelect=None needs to be documented (#20)

> An alternative solution is expose a mechanism to serialize a range of text including soft wraps as LF starting at some node all the way to the caret. Such an API allows authors to count the number of lines from the first line, or from the beginning of the physical line (i.e. the first character of wrapped lines the caret is currently in).

Yes, this is the box-tree API that is currently being worked on, as I understand it. But unless something more is added, this doesn't really say anything about where the caret is, because one range can be two different caret-positions (start or end of line). So the box tree model is a good idea, but I think it's something else than this.

> The information you've been us so far has been problems existing editors have encountered, and that unfortunately isn't really a good use case.

I understand what you are saying, but I don't think that is quite correct. Have you looked at the use cases I supplied? Or the ones Oxygen XML supplied? Most of Benjamin's editing explainer document is in large part based on Fidus Writer's needs.

Some of the other use cases that make it necessary to know where the caret is:

* An editor that wants to place the caret in the same place when the user returns to a previously saved document.
* A collaborative editor that wants to show the placement of the collaborators' carets.
* An editor that wants to implement movement in the block direction itself.

> Every year, hundreds of new APIs are proposed in Web Apps and other standards groups in W3C and yet all of them are initially wrong.

Sure, but in order to get it right, we should probably to continue to discuss based on the already given facts, and not restart the discussion from zero again.

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