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

@johanneswilm : Okay. Let me give you a concrete use case that necessities knowing whether the caret resides before or after a line wrap.  Suppose your editor needs to show a visual line number (i.e. wrapped lines will be treated like multiple lines) at which the caret currently resides.

One solution to address this use case is exposing whether the caret resides before or after a line wrap. If the editor can already determine where line wraps occur, such an information could help editor determine the line number.  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).

The only reason I've picked the first solution for now is because the second API is quite expensive to implement but there could be other reasons to prefer the second API or yet another API to solve the same problem. We don't know but it doesn't matter what solution we choose as long as we allow some editor needs to compute the visual line number.

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.  It's like telling your architect what problem(s) you have with your current home.  What an architect needs to know is what YOU WANT in your new home; e.g. kind of things you want to cook at your kitchen, the kind of guests you want to invite, the number of kids you want raise at your new home, etc...

Here's another observation.  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_.  It's not that people who came up with those were incompetent.  It's that other participants often realize subtle problems with their proposals or that they have other use cases to consider.  And the key to picking the right solution is by evaluating each API using the list of use cases we've accumulated.  Take a look at Hixie's proposal for dependency resolution: https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0277.html  He very carefully addresses each and every use case there.  Now, I think his API in that particular thread is a bit too complicated but even then we can discuss that constructively by trimming the API surface and see which use cases can still be satisfied.  Without such an exhaustive list of use cases, there isn't a good way to evaluate each proposal we make.

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