RE: Default Caret and Selection Positioning Spec?

Ah, I see what you're saying. I think it's more important to specify how we 'normalize' a given location where there are several possible places that the caret could be in the markup. Say the markup is <div>line <span>1</span></div><p>line 2</p> and the user clicks after the '1'. We should have consistent behavior for placing the caret inside or outside the div, the span, and the other div.

Even more important is that we allow script to modify the location of the caret with script and don't normalize it if they do so.

-----Original Message-----
From: Ryosuke Niwa [mailto:rniwa@apple.com] 
Sent: Monday, December 8, 2014 3:26 PM
To: Ben Peters
Cc: public-editing-tf
Subject: Re: Default Caret and Selection Positioning Spec?

We specify what happens when a caret is moved forwards or backwards logically, or when it's moved left or right visually.

However, we can't say what happens when a specific arrow key is pressed because that binding depends on the underlying platform.

Also, many Web browsers support moving across a word, line boundary, etc... and I don't think we can specify exactly that either because many languages require heuristics to determine a word boundary.

On Dec 9, 2014, at 6:22 AM, Ben Peters <Ben.Peters@microsoft.com> wrote:

> Why can't we say if the caret should move logically or visually forward? We can implement it either way regardless of the underlying platform, right?
> 
> -----Original Message-----
> From: Ryosuke Niwa [mailto:rniwa@apple.com]
> Sent: Monday, December 8, 2014 3:21 PM
> To: Ben Peters
> Cc: public-editing-tf
> Subject: Re: Default Caret and Selection Positioning Spec?
> 
> We can't do that because it's more of a UI/UX problem that depends on the underlying platform.
> 
> On Dec 9, 2014, at 6:19 AM, Ben Peters <Ben.Peters@microsoft.com> wrote:
> 
>> I think we should specify the way bidi text should work.
>> 
>> -----Original Message-----
>> From: Ryosuke Niwa [mailto:rniwa@apple.com]
>> Sent: Monday, December 8, 2014 3:05 PM
>> To: Ben Peters
>> Cc: public-editing-tf
>> Subject: Re: Default Caret and Selection Positioning Spec?
>> 
>> I think we should include this in the selection API specification.
>> 
>> Given different browsers support different modality of changing selection with respect to bidirectional text (e.g. moving caret to left/right visually versus moving caret forwards/backwards logically), I don't know how specific we can be though...
>> 
>> On Dec 9, 2014, at 1:49 AM, Ben Peters <Ben.Peters@microsoft.com> wrote:
>> 
>>> 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 23:35:49 UTC