Re: [editing] Should the caret move by default, and should we define this behavior? (#58)

OK. I will give some use-cases in which the default caret movement behaviour (today) is not suitable:
1. Change Tracking: the deleted content is rendered crossed out and the caret should not be placed by the used inside the crossed-out content. Note that the deleted content may span multiple nodes. E.g. 
```
<p>this <span class="del" data-cid="1">is a </span><b><span class="del" data-cid="1">deleted </span>frag</b></p>
```
 I don't want any caret position inside the two `.del` spans, nor between them.
2. Labels: intended to inform user about the content that would be inserted, but which are not editable
```
<p><b class="info">Chapter 1: </b> Title of chapter1</p>
```
 When the caret is in the `p` element, i want the caret to be anywhere after the `.info` element, but not inside or before it.
3. Structured information: the caret should not appear between two elements that cannot have anything between them. E.g.:
```
<p><span class="street">1, Townsend st.</span><span class="city">San Francisco</span><span class="zip">9401</span></p>
```
There should be no caret between the span elements, text entered there does not have any meaning.
4. Inline widgets:
```
<p><div class="button">expand</div> ... content ... </p>
```
There should be no caret inside the `.button` element.
5. Code folding:
```
<span class="folded-marker">[...]</span>
cod|e
```
When the user moves the caret up, the `.folded-marker` should appear focused (get some fancy blue border) and the caret should disappear. Moving the caret up again should show the caret on the line above the `.folded-marker`.


Some personal remarks:
- I think that platform-specific selection implementation is fundamental for accessibility and usability. I don't care if it is implemented by UA or script. 

 However, even with enough API (e.g. showing the magnifying glass on an iPad), this would be a huge task for editor devs. So, I imagine there will be a handful of libraries that will have to offer some API in order to be customized by each editor. So we are back to square one: designing an API for managing selection.
- If you override the selection once, the hidden selection-associated state (e.g. magic X coordinate in block-direction movement) gets out of sync, so one needs to override most of the subsequent selection changes.
- I would propose some CSS property or HTML attribute that controls where the UA is allowed to place the caret (a la `user-select`). The specification of the default selection behaviour should only define illegal caret positions. The script will still be able to place the caret in any position currently defined by this specification.

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