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

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

Assuming this extension is in sync with you, I have a few discussion points:

A. When selection is set by Selection API, should that go before #2 or after #2?
B. #2 is hard to spec and make interoperable. It'll also require
maintenance. What do you think, if browsers fire events, and it's JS
responsibility to do this?
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?

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

I'm new and my knowledge on existing bugs is very limited, but in my
understanding, browsers do pretty good job for 1/3/4. 3 and 4 look
poor to editor developers because #2 above is done by magic and
unpredictable, often set to selections to a surprising position. But
browsers honor the set selection for getSelection() and typing, though
the set selection might be awkward.

That's why I came up with 3 discussion points above. Am I still
missing something?

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

Not so fast. ce=true but user-select:none is one of complicated case,
I'll follow up on another thread on this.

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

As in item C above, if it comes to quite complex logic, or if it's
something that keeps evolving, I'd prefer doing it in JS. I don't have
clear idea which way we should go at this point though.

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

Please keep in mind that n-visible:1-document also exists, and n could
also be 0. This is the most complex part, and is likely to keep
evolving as we add features to HTML/CSS. My current preference is to
get this out of browsers and put into somewhere between browsers and
editors, implemented in JS; i.e., something Johannes named as "editor
jQuery".

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

Thank you for the clarifications. Now I understand it's probably
better to think this throughly, rather than one by one as they pop up
in mind. Whether this should go to Selection API spec or new Selection
Behavior spec, we could discuss once Ryosuke is back.

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

I see, so we'd switch behavior by cE. That explains Ben wrote "don't
change behavior of cE=true and it will stay unspec'ed and not
interoperable."

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

Thank you a lot for your support, Olivier!

/koji

Received on Monday, 8 December 2014 16:51:52 UTC