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

Going back to the original topic of this issue, which is about how the default selection behavior should be defined, we need to understand selection behavior requirements for each use case below, and understand why the current selection API is inadaquate:

1. Semantic HTML WYSIWYG editor
2. Structured content editor with whitelisted DOM elements and/or classes
3. Editor that supports areas of non-editable content
4. Web-based code editor with syntax highlighting
5. Browser based "word art" generator
6. Track changes functionality within an editor
7. Web-based DTP application
8. Surface for plain text editing
9. Style read-only text

For example, for 3, I'd imagine that selection cannot cross editability boundary so we need to spec how UA "fixes" selection when the selection is set across different editability.  Or maybe we need to allow it.  Or perhaps it needs to be configurable.

For 4, perhaps code highlighting happens asynchronusly so we need to provide a mechanism by which apps can replace the underlying DOM while preserving the selection set by the user.

And so forth.  Once we've listed all those requirements, we can then begin to think of a solution that address them.

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