RE: Manageable and predictable text insertion

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

Received on Wednesday, 12 November 2014 20:58:23 UTC