RE: Only Text Input and Intention Events

On Sat, Dec 6, 2014 at 8:06 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:
>
> Indeed. We have started discussing this here:
>
> https://github.com/w3c/selection-api/issues/27#issuecomment-65732595

Thank you for the link, it looks like we were discussing two different
things. The link is talking about an issue of inserting characters when
multiple DOM ranges belong to the same visual point. I agree that this
issue needs to be throughly discussed and solved.

But this is not specific to cursor movements. In my understanding, this is
part of the bigger issue where DOM ranges and visual points are n:n. This
could happen, for instance, when user clicked a point in a document and
starts typing. On the other hand, the opposite case (multiple visual point
mapping to the same DOM range) exists. Imagine the range you set selection
is at line wrapping. Should the caret displayed at the end of line, or at
the beginning of the next line? This could also occur in bi-di text.

The "n:n" could also be "n:0" if the element has display:none,
contenteditable=false, or user-select:none. "0:n" cases include generated
content such as list markers.

What I was talking about was more like UX. Where carets should when user
pressed the down arrow key for instance, e.g., which visual X should caret
move to.

> Not defining caret movement at all is also a possibility. But in that case
> it seems noone will be able to use the browser-builtin caret movement
logic,
> right? It seems like the answer then will have to be what it currently is:
> to replace all or most of caret movement with Javascript, so the only
major
> parts of contenditable left then are:
>
> 1) drawing the blinking caret (which isn't that hard to replicate in
> Javascript) and
> 2) multi-key character input
>
> If one goes that way it seems to me it may be an idea to just focus on 2
and
> throw contenteditable entirely away.

Assuming your "caret movement" is solving n:n issue, IIUC, I think we're at
the stage of trying to figure out which issues browsers should solve, and
which JS should solve.

I saw Olivier requesting browsers should never ever move the selection
range once set. Browsers can do that. But then it also means that, whenever
n:n issue needs to be solved, it'd be JS responsibilities to kick in and
solve.

My question then would be, is the additional responsibility clearly
understood and is that a consensus among editor developers, or is the
discussion still going on among editor developers? If that's the consensus
among editor developers, we'll need to figure out when browsers need to
solve n:n issue, and create event hooks for all such cases. But your
question above indicates me that such consensus was not built yet, correct?

Overall, I joined this group to hear what editor developers want and to
understand that better, so that browsers can give editors want they want,
and to provide the best experiences to end users as cooperative efforts.

What I understood at this point is that editor developers want browsers do
less. Ben's current proposal is to start from a minimal new architecture. I
think this is one good approach, because it'd then give no room for
browsers to do the magic they used to do.

If editor developers think it's way too much more than they want to take,
we could discuss to seek for other ways to share burdens.

>> If there were common handlers for any specific intents, I would prefer
>> to develop common JS library rather than defining precise spec and all
>> browsers implement them. That'd save us a lot of time to discuss the
>> best behavior, spec them, develop them, write tests, test them, and
>> fix bugs. It has other benefits as well such as someone who doesn't
>> like the common behavior can fork and modify for his/her purposes, or
>> you can fix issues by yourself rather than filing a bug and waiting
>> for a long time until problematic versions would be gone.
>
> I think you are somewhat right about this, but somehow conditions haven't
> been right so far. We editor developers are divided between several
> different editors with somewhat diffeent approaches building on more or
less
> of the available (oftentimes broken) APIs that can be used for editing;
> either entirely on currently contenteditable/designmode with little
> modifications (and lots of stuff breaking), or with heavy modifications to
> have things break less, or not with designmode/contenteditable at all
> drawing your own caret with more or less of a complex relation between DOM
> and data-representing JSON. Once one chooses one approach, one can't
really
> mix very well, and browsers often all these half-working solutions and
there
> hasn't been much of a signal which way it's going.

Thank you, I was not aware of this background very clearly.

> If browser makers could agree that contenteditable and designmode will be
> thrown out entirely, that would be a clear message and even though not the
> best solution for us who work with editors, it would mean we would have a
> clear picture of what we are looking at and possibly some common library
> that "every" editor uses (type jquery) could evolve from that. Or
> alternatively, as it was my understanding until now, that you guys go for
> the contenteditable=minimal route or even for spec'ing and fixing entirely
> the current contenteditable=true.

Interesting, I was thinking just opposite; if editor developers could agree
to want browsers to handle just typing, we can do that. I understood Ben's
proposal that way.

You listed 3 options:
1. contenteditable and designmode will be thrown out entirely
2. contenteditable=minimal route
3. Spec'ing and fixing entirely the current contenteditable=true

My impression was 1 and 2 are the same, renamed to contenteditable=typing.
What did I miss?

> The worst of all situations seems to be to continue what we have now: no
> specification on most editing-related things, yet two or more different
> alternative ways of editing html in the browser that are implemented
> differently in each browser and arbitrarily change in each browser with
> versions.

Yes, can't agree more. We're here to solve that, right? And I want to solve
that in the way where editor developers and end users being happy. I'm here
to learn and discuss how we can do that. Let's solve this together.

/koji