Re: Default Caret and Selection Positioning Spec?

I was not trying to say that rtl is not common. I just meant that
specifying caret behavior shouldn't be prevented by users switching between
rtl and ltr. If needed also this switch should be spec'ed.
But it sounds like you have found a solution already.
On Dec 9, 2014 3:34 PM, "Ryosuke Niwa" <rniwa@apple.com> wrote:

>
> On Dec 9, 2014, at 4:49 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
> Ok ok,
> but all those seem rather special cases.
>
>
> I kid you not; bidirectional text case is extremely common!  Since all
> numbers in Arabic and Hebrew are LTR unlike the rest of text, someone who
> write in Arabic and Hebrew as their primary languages encounters the
> scenario I outlined any time they have to write numbers.
>
> As long as the intentions behind the proposal made are covered by however
> you formulate it technically, I think that's all that matters.
>
> The important thing is that the current, rather arbitrary behavior in the
> more common cases is replaced by something that is predictable and the the
> same in the various browsers for those of us on the Javascript side.
>
>
> I think we can get most out of standardization by spec'ing the
> normalization behavior, and "intention" or "responsive input" events can
> tell us which arrow key will result or has resulted in which selection
> change.
>
> On Tue, Dec 9, 2014 at 12:28 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
>>
>> On Dec 9, 2014, at 1:06 AM, Johannes Wilm <johannes@fiduswriter.org>
>> wrote:
>>
>> Hey,
>> true, the normalization is important. We researched this a bit (
>> https://github.com/w3c/selection-api/issues/27#issuecomment-65732595 )
>> and it seems that there are currently two main "modes" of how this works:
>> In both cases the caret is outside the inline element if it is in front of
>> it. When the caret is behind the inline element, the location for text
>> input can either be (a) inside or (b) outside that element. Browser
>> behavior is not consistent on this. Some browsers seem to follow solution b
>> for A-elements and solution a for all other elements. Other browsers seem
>> to follow solution a for all elements. It would seem to make sense to
>> either clarify that solution a should be used for all elements, or that the
>> user can switch between solutions a and b using CSS (or some other
>> mechanism).
>>
>> As for some browsers on some systems having mapped the right and left
>> arrow the opposite way round: Can't you just replace the wording "left
>> arrow" with the appropriate professional terms to mean "whatever key to
>> move the caret in direction left"? For bidi text the inside/outside may
>> have to be switched.
>>
>>
>> No.
>>
>> Suppose we had, in logical order, abcDEF where a, b, c are LTR letters
>> and D, E, F are RTL letters (e.g. Hebrew letters).  If this sentence of
>> code points appear inside a LTR block, it will be rendered as:
>> abcFED
>>
>> If the caret is placed between c and F, the caret can be at either offset
>> 3 or 6 depending on the UA and the input method we're using.  Suppose it's
>> at offset 3. If we move to the right by one character visually, we must
>> move to offset 5 between E and F.  If we're offset 3 instead, then moving
>> to the left visually by one character require us to move to offset 2. In
>> either case, we're moving by more than one offset in logical/DOM order.
>>
>> Furthermore, in vertical writing mode, left and right arrow keys move
>> will cause the caret to move between lines, not between characters; up and
>> down arrow keys, instead, are used to navigate between letters and words.
>>
>> Also notice that we should have something in their on how to move across
>> certain types of line elements: So far we came to the conclusion that
>> inline elements which cannot be edited in a text editor (img, svg, video,
>> contenteditable=false, etc.) should be treated as single characters (the
>> caret has to be able to go on both sides of these elements), whereas
>> elements with display:none set should be treated as if it wasn't there, and
>> the caret should jump across it together with the first following
>> character.
>>
>>
>> On Tue, Dec 9, 2014 at 12:37 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>>> 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.
>>> >>>
>>> >>
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> Johannes Wilm
>> Fidus Writer
>> http://www.fiduswriter.org
>>
>>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>
>
>