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

On Sat Dec 06 2014 at 1:17:23 AM Koji Ishii <kojiishi@gmail.com> wrote:

> This is still different topic from the original subject, but since
> it's so good point that I'm changing the subject.
>

Thank-you for the thorough email.

You are right there are multiple things being discussed here but that is in
part because all the issues are inter-related.


> 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.


> 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.

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

The first one is fairly easy: you can't edit  images, video, cE=false,
etc...

The second is much harder and will demand a lot of work. We haven't started
but we should soon.

The last two we are starting to discuss as you saw on GitHub.

>
> * Should we show or hide carets if the selection is on display:none?


I think we'll end with the only logical conclusion that you can't edit what
you can't see, therefore invisible elements can't be edited, therefore as
per above: no caret.

>

* Should we simply hide caret and disable editing if the selection is
> moved to non-contenteditable?
>

Yes, if you ask me.

* What to do if the selection is on an element with CSS user-select
> property set to none?
>

Insofar as you can't modify what you can't place your cursor on, it seems
acceptable to treat userelect:none same as cE=false. But I'm open to other
views on that.

* That'd break a lot of sites. Are we ok with that?
>

No we don't want to do that. Any part of the spec that will break cE=true
 or anything else should be confined to cE=typing so it will not have
side-effects.

>
>
Can Ryosuke's Selection API spec cover all these? I guess it'd be then
> not Selection *API* spec any longer. I'm ok with either broaden the
> scope of the spec, or starts a new spec for Selection UI and carets,
> but either way, I think we need to fill in these pieces to make
> selections and editing interoperable and solve what Olivier really
> wants to solve.
>

Agreed. I think the Selection API alone won't be sufficient.

>
> Thoughts? Do I look on the right track?
>

Yes I think you're on the right track. Thanks!


>
> /koji
>