RE: Manageable and predictable text insertion

A novel approach, Oliver. I’m not sure we want to put the editor in an in-between state though. Average developers and users might have a hard time understanding what’s going on in this model. You do raise a good point though. If we have a ‘replace’ intention, it seems like script should be able to overwrite ‘delete’ and ‘insert’ separately. We should be sure that if script changes the selection (say be removing its contents) during an overwrite intention, the browser should be able to insert the characters correctly. I prefer to keep things in order. For Replace, this means Delete and then Insert. Does that cover your use case below?

From: Olivier F [mailto:teleclimber@gmail.com]
Sent: Thursday, October 9, 2014 8:27 PM
To: public-editing-tf@w3.org
Subject: 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.