Default Caret and Selection Positioning Spec?

Do we need a new spec to cover where the caret should be placed in the markup in contentEditable='typing', and where the begin/end of the Selection's range should be when selecting with mouse/keyboard?

On Mon, Dec 8, 2014 at 10:45 AM, Ben Peters <Ben.Peters@microsoft.com> wrote (http://lists.w3.org/Archives/Public/public-editing-tf/2014Dec/0029.html):
> 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:50:15 UTC