Re: Manageable and predictable text insertion

>
> It sounds like you're saying that a browser would insert the text before
> the deletion happens.


No, under my proposal deletion happens before insertion. It works like this:

1. User types a character on keyboard. This triggers an event, perhaps
"InsertIntent".
2. The editor script, which is listening for that event, checks to see if
any content is selected in the listener. If so, the editor script calls its
myDeleteSelection method from within the listener. Nodes are removed as
needed, and the selection may be collapsed and relocated.
3. The event then propagates to the browser's internal contentEditable
handler. because cE was set to "insertCharacters" mode, the cE goes ahead
and inserts the character that was typed just to the left of where the
cursor is located.

As you can see, Delete takes place in step 2, and Insert in step 3, so the
order is correct.

On Wed, Nov 12, 2014 at 12:57 PM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

> On Wed, Nov 12, 2014 at 9:59 AM, Piotr Koszuliński <
> p.koszulinski@cksource.com> wrote:
> > I was thinking about the same concept for CKEditor. If we let the browser
> > only insert characters, but make the editor handle the deleting part,
> then
> > we can achieve very consistent behaviour across all browsers even today.
> The
> > only tricky thing today is discovering when we should delete the selected
> > content. It's pretty obvious when the user is cutting, drag and dropping
> or
> > pressing backspace, but may be very hard when the user is typing because
> it
> > may not be obvious if this key will insert anything (although the new
> > KeyboardEvent.key property [1] helps a lot). This also proves how
> important
> > the intention events are.
> >
> > I'm not sure about one thing, though - whether we should split a single
> user
> > action like pressing a key into two intentions - deleting and inserting.
> > There are two options:
> >
> > 1. The action is split. In this case there should be a way to tell, while
> > handling one of the atomic intentions, to what action it's related. For
> > instance, how the delete intention should be handled may be dependent on
> > whether a backspace was pressed or a letter key. According to the Ben's
> > summary of TPAC [2] I suppose that that would be solved by the
> > 'intentionSrc' property.
> > 2. The action is not split so the default 'insert' intention handler
> deletes
> > the content and then inserts the character. I think that this option
> makes
> > it simpler to implement this concept for cE=true, because currently
> > intentions are handled by monolithic algorithms. The developer could
> have a
> > problem, though. If I want to handle the deletion part, I listen to the
> > 'insert' intention event, delete the content, make a collapsed selection
> and
> > let the browser insert the character. If I want to handle only the
> insertion
> > part I do what? I need to be able to reuse the the native deletion
> algorithm
> > which the browser would need to expose. We could say that there's the
> > 'delete' command which one can execute, but there are problems with
> commands
> > being too high-level features, so their reusability is questionable (e.g.
> > how would that be integrated with the native undo manager?).
>
> I currently prefer option 2, as noted in my reply to this thread.
> http://lists.w3.org/Archives/Public/public-editing-tf/2014Nov/0031.html
>
> > Furthermore, we are talking about having the contentEditable="deletion"
> [3]
> > which means that the deletion algorithm would need to be defined anyway.
> >
> > So the bottom line is that developers need reusable methods and this can
> be
> > achieved by splitting the intentions to atomic ones, or having more
> complex
> > intentions but adding more methods to the range or selection APIs. Both
> ways
> > will work, though the latter sounds like a better API.
>
> This is a good point. Can you add this use case to
> https://github.com/w3c/editing-explainer/issues/3 please?
>
> > PS. I'm starting to having doubts whether we need customisable default
> > handling with contenteditable [3], because the same may be handled by the
> > website if the granular methods are exposed well. Having cE customisable
> > will rise questions like what should insertHTML command does if
> 'multiline'
> > is not enabled and the HTML to insert consists of multiple paragraphs.
>
> I agree that we don't need to have multiple new types of contentEditable.
> It can be handled by Intentions using preventDefault().
>