Re: Default Caret and Selection Positioning Spec?

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

> 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.

Right.

> 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.

Yup.

> -----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:38:06 UTC