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

> When creating editors, do you ever want to save the selection to move it temporary, do something and then restore?

I don't "want to" and I try to avoid it, but there are situations that leave me unable to do it any other way. Take for example the case where my user creates a hyperlink. I will create a little popup toolbar that allows user to edit the url. But the moment the url input element gets the caret, the selection in the document has disappeared. Therefore I would "save" the selection based on what the Selection api gives me, then restore it when user is done editing url. There are ugly hacky workarounds that would leave the selection in place but I'd much prefer if the Selection could be saved and set without losing important state.

Sometimes it's also necessary to adjust the Selection because it is in an illegal place (with respect to my editor's logic).

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

Agreed this one is irrelevant for cE=typing.

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

Yes. I can't imagine writing an editor where I can't change the Selection.

I think the larger problem here is that the Selection API is a writable API, but there are internal states attached to Selections that aren't reflected in the API. How can this ever be problem free? If I have a writable API I am going to assume I can read and write to my heart's content. If there are hidden consequences to writing the API they should at the very least be documented, probably standardized, and ideally made writable too.




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