Manageable and predictable text insertion

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.