RE: setSelection, render carets, and starts edits (was Re: Only Text Input and Intention Events



On Sat, Dec 6, 2014 at 7:10 PM, Olivier Forget <teleclimber@gmail.com> wrote:
> Right, I think we'd be trying to change that pattern. The problem is the UA
> finally decides where text goes at the last step. I would prefer to see:
> 1. User clicks on content
> 2. document position is fully resolved by UA
> 3. if that document position is editable, show caret, if not (user clicked
> on an image or in cE=false) then don't
> 4. if there is a caret, then getSelection returns that exact position where
> text will be inserted if user types at that moment.
>
> What I'm saying is that the UA would need to maintain a one-to-one relation
> between the following things:
> - a blinking caret
> - a fully resolved unique position in the document
> - getSelection returns that exact position
> - user's typing inserts text at said position
>
> If for whatever reason selection is at a non-editable position, then there
> is no caret, and there is no insertion of text upon typing.
>
> This implies we need to spec a number of things:
> - what's editable and what's not?
> - where can text be inserted? (and how? can UA create text nodes?)
> - how to resolve 1-visible:n-document positions
> - caret movement via arrow keys as selection goes inside/outside elements,
> and around non-editable elements

This is a great start to a list. 1 and 2 should be in contentEditable. I filed https://github.com/w3c/editing-explainer/issues/21 for 2. 3 and 4 should be in Selection API or related. I'll start a thread for this.

Received on Monday, 8 December 2014 18:45:46 UTC