Re: Only Text Input and Intention Events

On Sun, Dec 7, 2014 at 1:06 AM, Koji Ishii <kojiishi@gmail.com> wrote:

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

The first post there mentions two issues related to carets. Subsequently we
have then discussed one of those issues. If we had a specific document to
only talk about carets, then that's probably where those two posts would go.

Or where else would you suggest for this to go?


>
> But this is not specific to cursor movements.


Well, it depends. If Olivier suggests that the text input is exact where
the selection/caret is, but that with moving the carets using arrow keys
(or mouseclicking) it will always be put in a "default" position when in a
certain place (for example when the caret is at the end of a link it will
always be "outside" the link and not "inside of it).


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


Sorry, I am not familiar with that n:n terminology,  but I think I
understood your point. Maybe from the perspective of someone programming a
browser issues of carets really belong together with a lot of other things
and don't need their own definition. From the perspective of an editor
developer, they seem like something quite unique that need their own
definitions.

What's your suggestion we should do?


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

Down and up arrow key movements are somewhat more complicated to implement
in Javascript, indeed, although some (like Aloha) are it anyway. I agree
that moving up and down may not have have to be done the same in all
browsers as long as all browsers follow common sense rules (like "don't
move the caret inside a noneditable area", etc.).

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

Indeed. The idea is to have it more modularized and  for the browser to
generally do less, as I understand it. But if the browser does something
(for example caret drawing and movement), it should do it well and
according to specs so that we an depend on this behavior, at least for
simple editors.  Advanced editors can always add their own behavior on top
if they want to do something even more interesting.


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

If it's spec'ed and implemented in most major browsers the same way, there
seems to be a good chance that editors will switch to this. If you remove
contenteditable=true, chances are even higher. :)


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


Well, there are many other options of course, those just examples. Under 1,
they would be thrown out and removed entirely without replacement. It was
from my impression at the web summit that the browser people felt that
contenteditable=true would stay around additionally to
contenteditable=minimal for a good while because they believed many legacy
systems depend on it.


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

Yepp :)


>
> /koji
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org