Need to specify which input types are handled by EditContext

[dandclark]

EditContext doesn't fire textupdate for every inputType. E.g. EditContext will fire textupdate for "insertText" but not for "formatBold". However this behavior doesn't actually seem to be in the spec.

It seems that it should be added to either the EditContext bullet point of https://w3c.github.io/input-events/#event-definitions or to https://w3c.github.io/edit-context/#dfn-handle-input-for-editcontext.

While we work this out, it would be a good time to review that we're sending the correct inputTypes to EditContext.
In the Chromium's implementation the list is:

• "insertText"
• "deleteContent"·
• "deleteWordBackward"
• "deleteWordForward"
• "deleteContentBackward"
• "deleteContentForward"

The intention here is that EditContext only handles changes that make sense for plain text, so things like bold/italic/underline are excluded. An interesting case to consider is that currently the Enter key is not handled by EditContext, because formatting for commands like "insertLineBreak" or "insertParagraph" can be nontrivial in rich text.

[johanneswilm]

As I understand the difference between an input type that is on this list and one that is not:

1. If a specific input type is on the list, then the browser will by default update the text state of the EditContext according to the default behavior of the browser. If the web author does not want this to happen, they need to preventDefault the before input event and update the text state manually.

2. If an input type is not on the list, then the text state will not be updated automatically and the web author will have to update it manually if needed.

A lot fo the input types will not normally lead to an update to the text state anyway because they deal with formatting or similar and so there is no need for manual update of the text state either.

The selection of input types may seem a bit arbitrary, almost no matter what one chooses. It looks like the criteria that has been used for this selection was:

• Remove all the input types that deal with formatting.
• Remove all the input types that deal with insertion of non-text content (lists, horizontal ruler, link).
• Remove all the input types that deal with the clipboard or clipboard-alike (paste/cut/yank/drop/drag).
• Remove all the input types that have to do with physical placement of content on the screen (softline deletions).
• Remove all the input types that deal with the document history.
• Remove all the input types that include additonal UI (spell checkers, LLMs, etc.)

This selection follows a certain logic. However, this still gives me a few more input types than what are currently selected, namely:

• "insertLineBreak"/"insertParagraph" - Will there be a difference between paragraph and line break in the text state of the EditContext? Or will the default for both just be the insertion of \n?
• "insertTranspose" - I wonder if the default is not best left to the browser as figuring out which were the last two characters entered and make them switch places could be quite complex in JavaScript. Note: transposing characters is not supported on most platforms.
• "deleteHardLineBackward"/"deleteHardLineForward" - If these are just deleting until the next \n in the text state, then they seem fairly similar to "deleteWordBackward"/"deleteWordForward".

Question: Would it be an option to not have any of the input types auto-update the text state to make it consistent? Or would that be impossible tdue to IME, etc.?

[dandclark]

Minutes from the April WG meeting:

[17:03] dandclark: we did discuss about this last time
[17:04] EditContext handles certain kinds of input, but doesn't handle formatting kinds of cases
[17:04] need to document better which should be handled
[17:05] the bullet points johanneswilm listed in the issue are a good starting point
[17:06] insertLineBreak and such can be complicated if the selection isn't collapsed
[17:07] EditContext wouldn't ever fire event for the cases when the internal state doesn't change
[17:08] q+
[17:08] dandclark: which commands should be handled automatically and which shouldn't?
[17:10] --> sanketj_ (~uid392014@9347813c.public.cloak) has joined this channel.
[17:10] johanneswilm: In many cases it would be good that browser takes care of the command. Author is still able to decide by cancelling beforeinput, correct?
[17:11] q+
[17:11] johanneswilm: is entering linebreak complicated also in text buffer case?
[17:11] dandclark: yeah, beforeinput can be cancelled
[17:12] dandclark: some of these commands rely on formatting context, I think
[17:13] ...which would be a clear reason why EditContext couldn't handle those, since it has just text buffer
[17:14] smaug: feels like this needs some more investigation
[17:15] johanneswilm: so dandclark will work on this more, and explain why each case should be excluded
[17:15] dandclark: feedback from other vendors would be good

[dandclark]

Going through each inputType defined at https://w3c.github.io/input-events/#interface-InputEvent-Attributes:

inputType	EditContext currently handles?	EditContext should handle?	Why?
"insertText"	Yes	Yes	Simple text-only operation
"insertReplacementText"	No	No	Typically involves other UI like spellcheck
"insertLineBreak"	No	No	Can be complex; see Chromium implementation. There is e.g. a question of whether to use a <br> vs a ‘\n’ and in certain cases extra linebreaks can be inserted.
"insertParagraph"	No	No	Complex command, relies on formats (InsertParagraphSeparatorCommand::DoApply).
"insertOrderedList"	No	No	Involves non-text content
"insertUnorderedList"	No	No	Involves non-text content
"insertHorizontalRule"	No	No	Involves non-text content
"insertFromYank"	No	No	Involves clipboard/dragdrop
"insertFromDrop"	No	No	Involves clipboard/dragdrop
"insertFromPaste"	No	No	Involves clipboard/dragdrop
"insertFromPasteAsQuotation"	N/A	No	Involves clipboard/dragdop. Also, Chromium doesn’t implement, do other engines support?
"insertTranspose"	No	Yes*	*This exists as “transpose” in Chromium. “insertTranspose” doesn’t exist in WebKit, not sure about “transpose”. Neither work in Firefox.
"insertCompositionText"	No	No	This event isn’t fired for EditContext
"insertLink"	No	No	Involves non-text content
"deleteWordBackward"	Yes	Yes	Core text-only editing operation
"deleteWordForward"	Yes	Yes	Core text-only editing operation
"deleteSoftLineBackward"	No	No	Involves formatting (line breaks)
"deleteSoftLineForward"	No	No	Involves formatting (line breaks)
"deleteEntireSoftLine"	No	No	Involves formatting (line breaks)
"deleteHardLineBackward"	No	No	Involves formatting (line breaks, block breaks)
"deleteHardLineForward"	No	No	Involves formatting (line breaks, block breaks)
"deleteByDrag"	No	No	Involves clipboard/dragdrop
"deleteByCut"	No	No	Involves clipboard/dragdrop
"deleteContent"	N/A	Yes?	Not implemented in Chromium. Do other engines implement?
"deleteContentBackward"	Yes	Yes	Simple text-only operation
"deleteContentForward"	Yes	Yes	Simple text-only operation
"historyUndo"	No	No	EditContext doesn’t have undo stack info
"historyRedo"	No	No	EditContext doesn’t have undo stack info
"formatBold"	No	No	Involves formatting
"formatItalic"	No	No	Involves formatting
"formatUnderline"	No	No	Involves formatting
"formatStrikeThrough"	No	No	Involves formatting
"formatSuperscript"	No	No	Involves formatting
"formatSubscript"	No	No	Involves formatting
"formatJustifyFull"	No	No	Involves formatting
"formatJustifyCenter"	No	No	Involves formatting
"formatJustifyRight"	No	No	Involves formatting
"formatJustifyLeft"	No	No	Involves formatting
"formatIndent"	No	No	Involves formatting
"formatOutdent"	No	No	Involves formatting
"formatRemove"	No	No	Involves formatting
"formatSetBlockTextDirection"	No	No	Involves formatting
"formatSetInlineTextDirection"	No	No	Involves formatting
"formatBackColor"	No	No	Involves formatting
"formatFontColor"	No	No	Involves formatting
"formatFontName"	No	No	Involves formatting

For the most part what my analysis of which commands EditContext should support matches what’s already been implemented in Chromium. One exception is “insertTranspose”, which EditContext could support, but the interoperability status of the “insertTranspose” is not clear. It exists under the name “transpose” in Chromium. In WebKit “insertTranspose” doesn’t exist -- not sure about “transpose” – and neither work in Firefox. I guess for browsers that implement it, under whatever name, EditContext should support it.

There's also a caveat about “deleteContent”. This is probably a candidate for EditContext to support, but contrary to my first comment in this thread, that command doesn’t actually exist in Chromium (only "deleteContentForward"/"deleteContentBackward" exist). Looks like Firefox also does not support it, but WebKit maybe does? In any case the spec should probably indicate it as supported by EditContext for browsers who implement the command.

[css-meeting-bot]

The Web Editing Working Group just discussed Need to specify which input types are handled by EditContext.

The full IRC log of that discussion

<sanketj_> Topic: Need to specify which input types are handled by EditContext
<sanketj_> github: https://github.com//issues/94
<sanketj_> dandclark: Issue is about which input types should be handled by EditContext
<sanketj_> ...: Ie. which which input types should change the text store and fire the textchange event
<sanketj_> ...: Unhandled types don't reflect in text store or event dispatch, authors need to handle this on their own
<sanketj_> ...: Chromium implement 5 of them (see issue)
<sanketj_> ...: Ask from last time was to inventory and check if there are any missing/incorrect ones.
<sanketj_> ...: Mostly right. insertTranspose is probably one that we should handle.
<sanketj_> ...: Not great interop on this one. Chromium and Safari use different names, and Firefox doesn't seem to implement.
<sanketj_> ...: However, should probably still include this in the supported list.
<sanketj_> ...: Similar caveat about deleteContent. Lack of interop.
<sanketj_> ...: In any case, deleteContent should also be added to the supported list.
<dandclark> https://w3c.github.io/input-events/#event-type-beforeinput
<sanketj_> ...: Propose that list of supported commands should be in the EditContext spec. EditContext dispatch conditions, based on input types, should go into input events.
<sanketj_> johanneswilm: Is there an input type in Chromium called "transpose"?
<sanketj_> dandclark: It is an execCommand.
<sanketj_> johanneswilm: Input types prefixed so that JS can clearly tell what happened and can be handled differently.
<sanketj_> ...: If really there is an input type that is not prefixed, that's a bug and should be fixed.
<sanketj_> ...: But execCommand may be different.
<sanketj_> dandclark: That's right. transpose is just the execCommand name. Input type for input event is insertTranspose.
<sanketj_> ...: Seems to only be invokable via execCommand
<sanketj_> johanneswilm: Is there not a keyboard shortcut?
<sanketj_> dandclark: Not sure.
<sanketj_> ...: In any case, input type does exist and anything that invokes that input type should be supported by EditContext.
<sanketj_> ...: Missed adding this earlier.
<sanketj_> johanneswilm: Sounds good.
<sanketj_> smaug: What about insertFromPasteAsQuotation? Supported in Firefox.
<sanketj_> dandclark: Copy/paste and clipboard related commands not included.
<sanketj_> johanneswilm: Will we explain what is supported and how they were chosen?
<sanketj_> dandclark: We can spec the fixed list and add some explanatory spec that describes the criteria used.
<sanketj_> johanneswilm: Sounds good to me.
<sanketj_> johanneswilm: Resolved to accept Dan's proposal.