Re: setSelection, render carets, and starts edits (was Re: Only Text Input and Intention Events

On Mon, Dec 8, 2014 at 8:51 AM, Koji Ishii <kojiishi@gmail.com> wrote:

> On Sun, Dec 7, 2014 at 12:10 PM, Olivier Forget <teleclimber@gmail.com>
> wrote:
> > On Sat Dec 06 2014 at 1:17:23 AM Koji Ishii <kojiishi@gmail.com> wrote:
> >>
> >> It's too broad that it has many cases inside. As Julie said in the
> >> comment, this requires selections set by DOM API should never change
> >> regardless of the conditions, and I suspect that is the intention of
> >> the bug,
> >
> > Not exactly no.That would be too strict. We need to allow the UA to
> change
> > the selection when the existing selection is made invalid (for example
> the
> > referenced elements are removed from the DOM.)
> >
> > Other than that the Selection might change because the user clicked on
> the
> > content or because they used the arrow keys.
>
> Ok, so UA needs to change selections, but only in the way it's clearly
> documented and predictable for editor developers. We'd then need to
> wait for the spec to know how to fix the bug.
>
> >> 1. JS calls setSelection() or user clicks to set a selection
> >> 1.5. JS may get selection to do other work
> >> 2. UA renders carets
> >> 3. When user starts typing, UA determines where to put those characters
> >
> > 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.
>
> Let me try to extend the list a bit more:
> 1. UA sets selection to one of possible ranges from user click, cursor
> move, etc.
> 2. Adjusts the selection to where it's valid to edit
> 3. if that document position is editable, show caret, if not
> 4. getSelection() returns the caret position if caret is visible
> 5. Creates text node when user starts typing, and the anchorNode is
> not text node
> 6. Insert typed characters into the text node
>

I don't quite agree with #2, at least how it's phrased. It depends on how
the process was started. It's more like this (in my view):
Entry via click:
1. User clicks
2. UA resolves document position. It may be that the user clicked on an
image, in which case it's not editable. If clicking in an editable area
there may be some ambiguities where there are 1:visible:n:document
positions. The spec clarifies the proper document position to use, and the
UA acts accordingly.
3. if position is editable, set the selection and go to 4 below

Entry via arrow keys:
1. User presses arrow key (note that for arrow keys to effect caret
movement, the caret must already be visible, ie: the selection must already
be editable)
2. A new editable position is calculated. There could be ambiguities
regarding the correct position. The spec should clarify proper caret
movement.
3. By definition the selection is editable, set selection, go to 4.

Entry via editor's setSelection:
1. editor calls setSelection
2. if editable go to 4. UA should NOT resolve ambiguities.

Entry via external factors: If the editable position is removed from DOM or
made non-editable, what do we do?
1. current editable selection made invalid
2. UA needs to unset selection or set it to something new //TODO
3. editor should have a way to know this happened. Does selection api
include selection events?

Once an editable selection is set:
4. selection is editable, so show a caret at the right place
5. getSelection returns the selection
6. typing inserts text at position indicated by the selection.


>
> C. I separated #5 because Ben's current proposal is browsers not to
> insert text if the selection is not on a text node. Could this also be
> done in JS?
>

Ben just opened an issue on GitHub on this. I'm looking forward to the
discussion.

>
> > The last two we are starting to discuss as you saw on GitHub.
>
> Please keep in mind that n-visible:1-document also exists,


You mentioned one example: the caret could either be at the end of the line
or at the beginning if the next line in case of a wrap. This doesn't really
matter to me, the editor developer. However I think the UA developers could
look at how existing rich editors handle these situations and do their best
to present an experience that is coherent for their users.

and n could
> also be 0.


Could you please give a specific example of 0-visible:1-editable? If you
are referring to the case of an editable element being hidden, we are
leaning heavily towards treating invisible elements as effectively
non-editable.