RE: Manageable and predictable text insertion

Got it. But if there is no handler in 2, then doesn’t it get into a strange state where characters are inserted while there is still a selection?

From: Olivier Forget [mailto:teleclimber@gmail.com]
Sent: Wednesday, November 12, 2014 1:58 PM
To: Ben Peters
Cc: Piotr Koszuliński; public-editing-tf@w3.org
Subject: 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<mailto:Ben.Peters@microsoft.com>> wrote:
On Wed, Nov 12, 2014 at 9:59 AM, Piotr Koszuliński <p.koszulinski@cksource.com<mailto: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().