RE: Default Caret and Selection Positioning Spec?

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:23:03 UTC