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

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

On Sat, Dec 6, 2014 at 2:31 AM, Olivier Forget <teleclimber@gmail.com> wrote:
> On Fri, Dec 5, 2014 at 8:57 AM, Koji Ishii <kojiishi@gmail.com> wrote:
>>
>> If you can't set the caret to a specific position by API, it's a bug
>> in browser. Please file bugs to browser vendors. I'd be curious to
>> know Blink bugs. I think it'd be great to share the bug number on this
>> ML unless someone thinks it's a noise.
>
> The bug is here:
> https://code.google.com/p/chromium/issues/detail?id=2874
> Note Julie Parent's plea for mercy way back in 2008. There has been some
> work on this recently but still no fix.
>
> There are many of examples like these in all browsers but most of them are
> ignored or given a "won't fix" because of a lack of clear direction from
> specs.

Thank you for the bug. This bug is a bit too broad, and also too narrow.

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, rather than just try to pass the cases in the attached test
file. That part must be spec'ed clearly as Julie and others say, but
we're here to do the work, not to ignore.

To spec it out, the bug is too narrow. Let me explain a bit what
happens within browsers (at least in WebKit/Blink.)

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

Now, there's logical contradiction between 1 and 3, because UA may not
be able to insert characters where selection was set. It may involve
adjusting selection, or creating text node, all such magic we -- both
UA developers and editor developers -- hate.

I actually had a discussion in my team to fix a selection bug to delay
the canonicalization up until it's really needed. If we do that, your
tests will pass, but since the canonicalization still occurs before 2
or 3, it makes nobody happy. I believe you'll agree that it's not what
you want.

So, let's say we spec that UA should never ever change selection set
by DOM API. That's an easy part; add a sentence to Selection API spec,
and we have an experimental patch. Your tests pass now, but then I'd
need other issues solved, such as:

* Should we show or hide carets if the selection is on display:none?
* Should we simply hide caret and disable editing if the selection is
moved to non-contenteditable?
* What to do if the selection is on an element with CSS user-select
property set to none?
* That'd break a lot of sites. Are we ok with that?
* And what to do when user starts typing?

contenteditable=typing and beforeinput should solve the last question
by saying "no magic". It should move all such magic from UA to JS
libraries so that it's clearer, predictable, and customizable.

Now I wonder, 3 pieces are missing (or just I don't know because I'm
newbie here ;)
1. Define setSelection more precise so that how it affects to
consecutive calls to get selections.
2. How UA sets selections internally when user clicks.
3. How UA renders carets, or not to render carets, especially when
selection is set to weird places.

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.

Thoughts? Do I look on the right track?

/koji

Received on Saturday, 6 December 2014 09:17:49 UTC