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

Caret movement ideas from Olivier http://lists.w3.org/Archives/Public/public-editing-tf/2014Dec/0031.html):
Entry via click:
1. User clicks 
2. UA resolves document position. It may be that the user clicked on an image, in which case it's not editable. If clicking in an editable area there may be some ambiguities where there are 1:visible:n:document positions. The spec clarifies the proper document position to use, and the UA acts accordingly.
3. if position is editable, set the selection and go to 4 below

Entry via arrow keys:
1. User presses arrow key (note that for arrow keys to effect caret movement, the caret must already be visible, ie: the selection must already be editable)
2. A new editable position is calculated. There could be ambiguities regarding the correct position. The spec should clarify proper caret movement.
3. By definition the selection is editable, set selection, go to 4.

Entry via editor's setSelection:
1. editor calls setSelection
2. if editable go to 4. UA should NOT resolve ambiguities.

Entry via external factors: If the editable position is removed from DOM or made non-editable, what do we do?
1. current editable selection made invalid
2. UA needs to unset selection or set it to something new //TODO
3. editor should have a way to know this happened. Does selection api include selection events?

Once an editable selection is set:
4. selection is editable, so show a caret at the right place
5. getSelection returns the selection
6. typing inserts text at position indicated by the selection.


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