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

The selection Api so far doesn't talk about changing the selection when moving the caret. 

This will only apply when cE=typing and cE=true are specified, so it may have to go into another document. 

If it's not specified anywhere, and browsers choose to implement it different, we won't be sure so we will need to continue to interrupt each key stroke event to check whether the caret may be at the border of an element before letting it do its default action. Then it may be easier to use a hidden textarea for input instead of cE=typing.

Two issues come to mind:

1. Caret at the end of an inline element

<p>Hello <i>Austri|a</i></p> ( | = caret)

If the user hits the right-key and then enters a "!", where should that end?

<p>Hello <i>Austria</i>!|</p> or  <p>Hello <i>Austria!|</i></p> ?

And what is the intermediate step? To the user, these two situations will look the same:

<p>Hello <i>Austria</i>|</p> and <p>Hello <i>Austria|</i></p>

so it seems it would be reasonable that they will behave the same as well.

2. It should be ensured that the movement of the caret is the same in all browsers. 

There are some well-known issues with that now, mostly related to the caret "jumping" another character when moving across inline void elements, foreign elements (SVGs) or elements that are specified as being noneditable or the caret not being able to go certain places (such as before one of the before mentioned elements when these are at the start of a block element).  In all these cases, I believe it should be specified that these elements should be treated like single characters in relation to caret movement.

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

Received on Thursday, 4 December 2014 20:16:51 UTC