Keep native browser behavior for prevented `beforeinput` events

[Comandeer]

Sometimes user input is connected with a native browser/OS behavior, e.g.

• pressing Enter inserts a new line and triggers autocorrection,
• double pressing space inserts a period.

However, RTEs often want to prevent the beforeinput events to be able to customize the input, e.g. preventing beforeinput after pressing Enter to insert a new paragraph. Such prevention disables the native browser behavior. There should be a way to keep the behavior but without the input, e.g.

• pressing Enter does not insert a new line but triggers autocorrection,
• double pressing space insert a period regardless of how many beforeinput events have been prevented.

Some loose ideas of how such API could work:

• a new parameter to the event.preventDefault() to allow native behavior – event.preventDefault( { behavior: true } ),
• a new method on the event to prevent only input – event.preventInput(),
• a new method on the event to trigger native behavior manually – event.fireConnectedBehavior().

[johanneswilm]

From TPAC 2024 minutes:

w3c/input-events#161

Tomasz: When doing beforeinput cancelltion, it also cancels other related things such as autocorrect, two spaces give a perido, etc.

Sanket: We should keep to existing model. Maybe add a second APi to do auto correction. Would that fix it?

Tomasz: Only in this case.There are other things like auto-capitalization, etc.

Dan: What if you had three events?

Johannes: What if the editor doesn’t update the dom on one of the first two events? Could this not be solved with EditContext instead?

Sanket: It still makes sense to me. It only happens on specific keys. … Maybe something to put on EditContext.

Sanket: I think we need a way to trigger the autocorrect.

Dan: Same privacy issues (on Mac)

Ryosuke: At the same time we need to support this.

Johannes: Ryosuke, do you agree that it should no t be an issue in EditContext [explain]?

Ryosuke: Yes

Olli: But we also need to support this in other places - like textinput, etc.

Siye: The event should still be triggered, even if prevent default was called on an enter-event.

Dan: That is risky. We need more time. Difficult to fix without privacy issues.

RESOLUTION: We try to think about a solution. Table until next meeting.

Dan difference to spell checking: less privacy issue as the JS cannot see wha words are underlined and the user has to decide

[smaug----]

This is possibly a tiny bit related to #160, when it comes to handling enter key.

[vlakoff]

I thought a bit about this issue.

• a new parameter to the event.preventDefault() to allow native behavior – event.preventDefault( { behavior: true } ),
• a new method on the event to prevent only input – event.preventInput(),
• a new method on the event to trigger native behavior manually – event.fireConnectedBehavior().

Initially, I figured out as well these three approaches.

Then, I mainly considered the double pressing of space. Generally, a succession of inputs, with the first one(s) being "remembered" and the last one additionally triggering another behavior.

• It rules out approach 3:

• a new method on the event to trigger native behavior manually – event.fireConnectedBehavior().

The browser behavior having been disabled during the first input, bringing it back during the second input seems to be compromised.

• I'm unusure about approach 2 (edit: finally, I ruled it out):

• a new method on the event to prevent only input – event.preventInput(),

At some point, I ruled it out too, but I can't even remember why. Thinking about it again, it looks like an acceptable solution.

Thinking about it again again, it sounds strange to prevent inputs, but still allow autocorrection, etc. That's really a RTE thing. Although the use case is desired, and advisable, such preventInput() method would be very specific actually.

Worse, it could bring confusion to web developers, as they would have to figure out why two prevent*() methods are offered. They could even use preventInput() instead of preventDefault(), as both would initially seem to behave the same, but they could then be confused when noticing that some browser autopunctuation, etc. unexpectedly happens.

• And about approach 1:

• a new parameter to the event.preventDefault() to allow native behavior – event.preventDefault( { behavior: true } ),

I figured out something like:

event.preventDefault( { allowInput: false, allowSubmit: false, allowAutomation: false } )

• "allowAutomation" is the least bad name I could come up with. We need something very general, yet descriptive.
• By default, all actions should be discarded (as it is the case currently, except for form submissions on Firefox, see #156 and #160). Then, on a kind of exceptional basis, we could allow some behaviors. allowAutomation: true may be the most useful one, but the other twos might have use cases too, even if rare.
• It could even be refined at a later time, adding allowAutocorrection, allowAutopunctuation, allowAutocompletion… and the existing allowAutomation would simply be a superset of them.

[vlakoff]

Rather than allowAutomation (which I don't really like), I just figured out allowPostprocessing.

• I like the similarity with video post-processing.
• I'm considering postprocessing as a single word (i.e. allowPostprocessing and not allowPostProcessing), as it is the most modern spelling (such hyphens are disappearing), and arguably the best capitalization for the case at hand.

[vlakoff]

However, preventDefault is used in many events and elements, not just text inputs, so "allowPostprocessing" might be confusing in other, unrelated contexts.

Hmm… maybe "allowTextProcessing"?