Re: Manageable and predictable text insertion

Hi Ben, thanks for commenting on my email.

On Mon, Nov 10, 2014 at 1:33 PM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

>  A novel approach, Oliver. I’m not sure we want to put the editor in an
> in-between state though.
>

I'm not sure what you mean by in-between state?


> If we have a ‘replace’ intention, it seems like script should be able to
> overwrite ‘delete’ and ‘insert’ separately.
>

Right, and that's the problem as I see it. Is there any precedent for
overriding/canceling part of an event but not another part? That sounds
problematic to me.


>  I prefer to keep things in order. For Replace, this means Delete and then
> Insert. Does that cover your use case below?
>

Indeed we should split the "Replace" intent into two intents: "Delete"
first, then "Insert" second when the user types over selected text. This
would be a good thing.

My proposal does not change the order in which things happen.
cE=insertChars simply says that when the user intends to type characters
(ie the "Insert" intent fires), they show up in the DOM next to where the
cursor is.

Deletion still happens, in the case of user typing over selection, but it's
handled separately, either by listening for a "Delete" intent or by
inferring it from the fact that text is selected and the user is typing.




>
>
> *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.
>
>
>