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

@ctalau: I think we need to make a distinction between selection as meaning "the user highlights something" and "the user moves the caret"/"the user inserts something at the caret position". They may both have selection at their base, but I have a feeling their are handled quite differently by editors:

* Caret movement/character insertion at caret place: The automatic caret positioning is almost entirely disregarded. At least one has a function in there that checks after each insertion or caret movement where the caret is and if it is not where one wants it to be, one moves it. For character insertions in places where the caret won't go by itself, it is not an uncommon practice in the JS code to first insert something in the place where one wants the character to go and highlight that, and then let the insertion event go which means that the new character will overwrite what one puts there in the meantime. If one tries to do several complex things simultaneously (for example: track changes, move caret around non-editable islands and islands with lakes, and collaborative with other users users by sending diffs over the networks) one may end up changing the selection programmatically up to 10-20 times in the process of inserting just a single new character. If one needs to move the c
 aret to places where the browser refuses to draw it (between two SVGs, for example), moving the caret there can for example be achieved by inserting a zero-width space character there and removing it again when the caret goes somewhere else. Caret movement therefore at times also means content insertion/deletion.
* Content selection: The user marks part of the content -- part of a sentence or several paragraphs. Here I have felt little need for intervention on the part of the JS code, at least as long as the user does nothing more. Should the user decide to want to delete the selected content or alike, the JS code likely will need to intervene again.

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

Received on Thursday, 4 June 2015 16:41:39 UTC