How does cE=typing work with overtype (insert key is on)

[BenjamP]

From MS Office Team

[teleclimber]

There are a few ways to approach this:

1. add a "overwrite" flag to the typing intent event, and let editor dev deal with deleting a character and placing the caret
2. add an "overwrite" flag to typing intent event, but the value is the range that the UA thinks should be deleted. Editor dev can delete that range or a different one. UA won't delete anything on its own. After event is allowed to continue UA performs the text insert at caret.
3. Let the default behavior of cE allow deleting a character to perform "overwrite" mode without developer involvement.

Number 3 is not that different from autocorrect as I currently envision it, but we haven't talked about how autocorrect works in cE=typing.

I don't know what the right answer is but we should try to make it so that autocorrect, overwrite, IMEs and any other mode that may want to modify text nodes beyond simple insertion all work in similar ways.

[fredck]

I'm starting to think that simple delete operations should be handled in cE=typing. This may be true for the DEL/BACKSPACE keys as well. It is a matter of defining the cases that can be handled.

Much probably the case is pretty simply: collapsed selection next to a character (present in next or following text nodes). If any element is in the path, nothing happens but the intention event is fired anyway, allowing js to (1) move the selection to an appropriate place where the browser can perform deletion or (2) perform the deletion by itself.

[rniwa]

I don't think so. It would be extremely confusing for developers if only some deletions result in DOM modifications. Also, a simple case that results in a trimming of a single character in a Text node can trivially be implemented in JS.

[fredck]

It would be extremely confusing for developers if only some deletions result in DOM modifications.

I agree.

we should try to make it so that autocorrect, overwrite, IMEs and any other mode that may want to modify text nodes beyond simple insertion all work in similar ways.

I don't think that putting overwrite (OW) in the same basket as autocorrect (AC) and IME is right. While OW must work over complex DOM structures (e.g. 1|<b>23</b>) AC and IME deal with "pure" text nodes. Their operations are much simpler. Therefore, maybe something like this makes more sense:

• OW: fires a "typing" intent event with the additional "overwrite" flag you proposed. JS will handle the deletion and the positioning of the selection in the right place, just like a normal "typing" intent.
• AC, IME, Spell-Checker, etc: fires a "replace" (or "rewrite") intent, with the range to be replaced and the text to be inserted. JS may change the range or change the text before the browser performs the action.

[rniwa]

OW can also be modeled as a forward delete immediately followed by an input. That might be better than forcing authors to support two modes of "typing".

[teleclimber]

It would be extremely confusing for developers if only some deletions result in DOM modifications.

@rniwa by DOM modifications do you mean Element node modifications or any node modification (including text nodes)?

Should we decide that cE=typing has a default action for backspace and delete then I believe this default behavior would only affect text nodes. The behavior would be to eliminate the character just before the caret (in the case of backspace), and if the character is at offset=0 of a text node, then it finds the previous text node and continues there. It would be up to the editor dev to clean up empty Element nodes as this happens, or relocate the caret as necessary before allowing the event to continue.

I think this would be reasonable.

I don't think that putting overwrite (OW) in the same basket as autocorrect (AC) and IME is right. While OW must work over complex DOM structures (e.g. 1|23)

@fredck agreed. Not only that, but more critically OW is a "combination intent": Delete + Insert in one default behavior. As we've seen a few months ago combo events are bad because the editor dev can't prevent one part but not the other.

AC and IME deal with "pure" text nodes.

@fredck are we sure of this wrt to AC?

Try putting mi<b>r</b>iad in Safari. If you right click on it, it will suggest 'myriad' (on my English-language Mac) and if you apply the correction it zaps the bold element.

On the one hand "real" text editors should be able to autocorrect partially-styled words. On the other, given we're trying to do something minimalist and workable with cE=typing maybe we could spec that autocorrect only operates on individual text nodes. We could tackle a full fledged AC API in V2.

[fredck]

we're trying to do something minimalist and workable with cE=typing maybe we could spec that autocorrect only operates on individual text nodes

So far cE=typing has been all about touching/producing text nodes only. Therefore I think we should indeed keep things simple and stick with this approach... at least for v1.

[rniwa]

End users don't care whether a word reside entirely inside a single text node or appears across multiple text nodes/elements. It would be a terrible user experience if autocorrection worked only in some cases.

As such, I'm strongly opposed to making anything work just in text nodes.

[teleclimber]

Since this issue is about Overtype and it seems we won't treat AC, OW and IMEs all the same, I created a new issue for discussing AC: #37 with my thoughts. Let's continue that discussion there.

[johanneswilm]

This seems to be covered by the current draft. Please reopen if I am wrong.