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

> > * 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.

> These are good use cases.

> >  * An editor that wants to implement movement in the block direction itself.

> This is not.  This is _what_ an app wants to do.  A use case is _why_ it wants to do it.

Ok, well this is a use case for why one needs to know the position of the caret. If I understand you right, you want to go one step beyond that and ask: "Is there really any reason for why the editor needs to be able to move the caret in the block direction?" correct? 

Some use  have been mentioned in other threads already (see below link). Some more:

* To create a "tracked changes" system where the caret should move into certain parts and avoid other parts. The caret should navigate around areas that have been deleted.
* Within an editor, there may be parts that are only editable once the users enters into them with the caret. In the case of Fidus Writer we have latex formulas that are usually shown as rendered formulas in the editor using mathjax, but once the user moves the care t there, it should turn into an input field in which the user can enter the formula. And the caret should be placed where it should have been usually. Imagine this:

```
<div contentEditable="typing">
<p>This is a normal |text line</p>
<p>This line contains a <span class="formula"><svg ...></span>.</p>
<p>This is the line after the line with the formula</p>
</div>
```
| = caret
If the user hits the down arrow, it should turn into this:

<div contentEditable="typing">
<p>This is a normal text line</p>
<p>This line contains a <span class="formula open">X^2=3y*6|5K</span>.</p>
<p>This is the line after the line with the formula</p>
</div>
```


* To have consistent behavior of caret movement across browsers, especially if browsers each will implement caret movement differently. Imagine a class of 90 year old IT first timers. Half come with Macbooks, some with Chromebooks and some with computers locked down to only be able to use Internet Explorer on Windows 7. The teacher tells them "click in the first line after the tenth letter, then hit the arrow down" and all of the browsers do different things because the editor developers had no way to standardize behavior.
* To have custom caret movement that matches the personal preferences of the editor develoeprs. Take for example this one:

```
<div contentEditable="typing">
<p>hello |mellow</p>
<figure>
  <img ...>
  <figcaption>A nice figure</figcaption>
</figure>
</div>
<p>A sentence after the figure</p>
```
| = caret.

If the user moves the caret down, one could imagine several different things happening, some of which are:

1. The caret moves into the figcaption just below where it was previously.
2. The caret moves before the figure.
3. The caret moves after the figure.
4. The caret moves into the paragraph after the figure.

All of these seem like valid ideas, and depending on what kind of text we are editing and what the preferences of the end users and editor developers are, any of these (and probably many others) could be possible and valid editor behaviors.

> > 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.

> That's just not how we design/standardize new APIs.  You're free to propose whatever you want but you won't persuade browser vendor to implement them with an argument like that.

I think you must be referring to something else. I was referring to the fact that we now mentioned these same use cases several times already and we shouldn't just forget about that and start from zero every few days. See here for example: https://github.com/w3c/editing/issues/56#issuecomment-108086579

There are some more use cases there.

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