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

Great conversation here. Let’s try to track this in bugs. I added Olivier’s comments to https://github.com/w3c/selection-api/issues/27.


From: Olivier Forget [mailto:teleclimber@gmail.com]
Sent: Monday, December 8, 2014 11:34 AM
To: Koji Ishii
Cc: Johannes Wilm; Ben Peters; public-editing-tf
Subject: 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<mailto:kojiishi@gmail.com>> wrote:
On Sun, Dec 7, 2014 at 12:10 PM, Olivier Forget <teleclimber@gmail.com<mailto:teleclimber@gmail.com>> wrote:
> On Sat Dec 06 2014 at 1:17:23 AM Koji Ishii <kojiishi@gmail.com<mailto: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.