Re: Manageable and predictable text insertion

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

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.

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.



[1] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.key
[2] http://lists.w3.org/Archives/Public/public-editing-tf/2014Nov/0000.html
[3]
http://w3c.github.io/editing-explainer/#customizable-default-handling-with-contenteditable

On Fri, Oct 10, 2014 at 5:26 AM, Olivier F <teleclimber@gmail.com> wrote:

> Hi everyone,
>
> It seems each time we look at how cE=min should handle text input we end
> up with one of two problems:
>
> - If cE=min handles text input and user inputs text while content is
> selected, the selected contents should be deleted. This leads to a hornet's
> nest because there is no standard way to handle how elements should be
> merged, etc... In our current thinking on text insertion, typing a single
> character can imply significant changes to the Elements of the DOM. cE=true
> behaves like this and that results in significant gripes from the developer
> community.
>
> - On the other hand if cE=min does not handle the text insertion itself
> but emits intention events, that means the spec somehow has to define
> events that can convey that the user is in the midst of typing an accented
> character or is using some IME. Additionally that leaves the editor dev
> with the burden of implementing all these details in their editor, which is
> very difficult, error prone and can lead to non-native look and experience.
> Some of the issues were laid out in this email:
> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0839.html
>
> The frustrating thing is that personally I have no complaints about text
> input itself in contentEditable=true. The gripes editor devs have with
> cE=true are mostly related to Elements being created or deleted. Text
> insertion itself, and particularly since it takes care of international
> character input courtesy of the underlying OS, is a good thing to have.
>
> Therefore I propose an "insertCharacters" capability for cE=min that does
> the following:
> "When the user intends to input characters, cE should insert these
> characters just before the selection."
>
> That's it.
>
> If the selection is collapsed and the user types 'a', then it behaves as
> one would expect: an "a" is inserted in the text node just before the
> cursor (to its left in LtR text) and the user can continue typing.
>
> If the user types an "a" while there is some content selected, an "a" is
> inserted just before the beginning the selection, but the contents of the
> selection are not deleted. Instead the editor dev listens for text
> insertion events and checks whether anything is selected when the event
> fires. If something is selected they can delete the selected content and
> relocate the cursor as they see fit from within the handler. Then they
> allow the event to continue which will result in the browser inserting the
> typed character to the left of wherever the cursor ended up.
>
> If the user is using T9, or typing accented characters in one of the
> various methods, or is using autocorrect the browser can alter the text
> adjacent to selection (including rendering hints like blue squiggly lines
> etc...) as needed to match the expected behavior.
>
> The following keys are not considered "characters" under this proposal and
> have no effect: Backspace, Delete, Enter/Return. Editor dev should listen
> for them separately and deal with them as they see fit, as they would with
> cE=cursor.
>
> Setting contentEditable="insertCharacters" implies the "cursor" mode of cE
> for obvious reasons.
>
> In my view the advantages are:
> - no need to come up with a spec that defines character entry events that
> account for all types of entry (see R Berjon's email). Editor devs just
> need to know that "something" is being typed.
> - no need to define how DOM Elements are added or removed based on user
> input
> - give editor devs predictable and manageable text insertion that doesn't
> mess with the Elements of their DOM
> - users get native character input and autocorrect which is what they
> expect.
>
> I am sure there are issues with this and there certainly are edge cases to
> consider but I look forward to hearing what you think.
>
> Regards,
>
> Olivier.
>
>


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter <http://twitter.com/ckeditor> | Facebook
<http://www.facebook.com/ckeditor> | Google+
<https://plus.google.com/107736718646302128806> | LinkedIn
<http://www.linkedin.com/company/cksource>