Re: [selection-api] caret-based selection movement (#27)

Actually I take that back. In Google Docs it's outside ~ outside as you've noticed. However, when the cursor is at the end of the link, the [U] (underline) button is depressed and the text-color button indicates the color is blue giving the impression that it's outside-inside. However, once you start typing that all goes away and you're inserting unstyled text.

I agree that it's probably because it's easier to cancel a '<i>' than an '<a>' that the behavior is different. I really don't love that there are two behaviors, but it seems that if most existing rich editors do it this way it would be sensible to specify:
- outside ~ inside for all inline elements
- except for '<a>' elements where it's outside ~ outside .

Are there other elements/situations to consider?

One caveat is that this should only apply to inline elements. For block elements we probably need to think about this some more.

Another aspect to look into which is very important is the relationship between the data provided by the getSelection API versus where text actually ends up going upon typing. To me, for the sake of developer experience there is no question it should 1-to-1: text gets inserted wherever the selection API says the caret is. For that to work the selection API has to be able to convey that info accurately under all circumstances. I'm not 100% sure it can do that yet. Need to look into it.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/27#issuecomment-65818219