Re: [editing-explainer] Target range in device independent events (#39)

IME is likely to require this issue to be resolved, but I'm guessing this issue affects more, and "how more" is what I'd like to ask you all.

When creating editors, do you ever want to save the selection to move it temporary, do something and then restore? Co-authoring is one likely case I found, and IME is one likely victim by doing so. But there are several information browsers keep internally along with the selection. Examples are:
* Information to solve ambiguity when DOM-to-visual is 1:n. WebKit/Blink has this, or something similar to https://github.com/w3c/selection-api/issues/32
* WebKit/Blink keeps whether the selection granularity is character/word/etc.
* Maybe not necessary for cE=typing, but the style last deleted/typed is also stored, so that when you delete all of bold words and then start typing, bold is applied.

There may be more, and we may add more in future. All these will be lost if you `getRangeAt` to save and then `addRange` later to restore. I hope you understand that solving this issue is more important than just for IME.

So, is it real, not only my guess, that editors want to modify other than selections, or want to save/restore selections for whatever reasons?

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