Re: Default Caret and Selection Positioning Spec?

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.

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