{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/editing-explainer/issues/39","labels_url":"https://api.github.com/repos/w3c/editing-explainer/issues/39/labels{/name}","comments_url":"https://api.github.com/repos/w3c/editing-explainer/issues/39/comments","events_url":"https://api.github.com/repos/w3c/editing-explainer/issues/39/events","html_url":"https://github.com/w3c/editing-explainer/issues/39","id":53959791,"number":39,"title":"Target range in device independent events","user":{"login":"kojiishi","id":1274377,"avatar_url":"https://avatars.githubusercontent.com/u/1274377?v=3","gravatar_id":"","url":"https://api.github.com/users/kojiishi","html_url":"https://github.com/kojiishi","followers_url":"https://api.github.com/users/kojiishi/followers","following_url":"https://api.github.com/users/kojiishi/following{/other_user}","gists_url":"https://api.github.com/users/kojiishi/gists{/gist_id}","starred_url":"https://api.github.com/users/kojiishi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kojiishi/subscriptions","organizations_url":"https://api.github.com/users/kojiishi/orgs","repos_url":"https://api.github.com/users/kojiishi/repos","events_url":"https://api.github.com/users/kojiishi/events{/privacy}","received_events_url":"https://api.github.com/users/kojiishi/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-01-10T14:32:47Z","updated_at":"2015-01-17T18:32:09Z","closed_at":null,"body":"@BenjamP mentioned the co-editing scenario in the issue #18, and that makes me wonder maybe we should have a target range in device independent events.\r\n\r\nCurrently, we translate, say, a keyboard event `Ctrl+B` to a device independent event `Bold`, and it executes against the current selection. But if an editor wants to bold anywhere other than the current selection, the options are either to do it by own, or move the selection tentatively and move it back. The latter is likely to results in bad UX, and also could introduce weird bugs.\r\n\r\nThe proposal is, instead, `Ctrl+B` is translated to `Bold this range` with the targetRange set to the selection.\r\n\r\nWe can't then re-use `execCommand` or exiting code as is, but I assume we won't, so this change should not add a lot of work. Or is it only for Blink and WebKit?"},"comment":{"url":"https://api.github.com/repos/w3c/editing-explainer/issues/comments/70378225","html_url":"https://github.com/w3c/editing-explainer/issues/39#issuecomment-70378225","issue_url":"https://api.github.com/repos/w3c/editing-explainer/issues/39","id":70378225,"user":{"login":"teleclimber","id":5631748,"avatar_url":"https://avatars.githubusercontent.com/u/5631748?v=3","gravatar_id":"","url":"https://api.github.com/users/teleclimber","html_url":"https://github.com/teleclimber","followers_url":"https://api.github.com/users/teleclimber/followers","following_url":"https://api.github.com/users/teleclimber/following{/other_user}","gists_url":"https://api.github.com/users/teleclimber/gists{/gist_id}","starred_url":"https://api.github.com/users/teleclimber/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/teleclimber/subscriptions","organizations_url":"https://api.github.com/users/teleclimber/orgs","repos_url":"https://api.github.com/users/teleclimber/repos","events_url":"https://api.github.com/users/teleclimber/events{/privacy}","received_events_url":"https://api.github.com/users/teleclimber/received_events","type":"User","site_admin":false},"created_at":"2015-01-17T18:32:09Z","updated_at":"2015-01-17T18:32:09Z","body":"> When creating editors, do you ever want to save the selection to move it temporary, do something and then restore?\r\n\r\nI 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.\r\n\r\nSometimes it's also necessary to adjust the Selection because it is in an illegal place (with respect to my editor's logic).\r\n\r\n> 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.\r\n\r\nAgreed this one is irrelevant for cE=typing.\r\n\r\n> 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?\r\n\r\nYes. I can't imagine writing an editor where I can't change the Selection.\r\n\r\nI 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.\r\n\r\n\r\n"}}