Open siliu1 opened 1 month ago
@siliu1 This makes sense. But is this not what the spec requires already (also for other input types)? Is there an implementation that does not follow this order?
@johanneswilm I think the focus of this proposal are:
beforeinput
and input
events are insertReplacementText
.@siliu1 Point 1 sounds like a potential bug in specific browsers to me (which ones?). This is already specified in the spec. On point 2 - I don't recall us having specified anywhere that certain input types should NOT have composition events. But I think that's because it should be obvious when no composition takes place and would probably be considered a bug already. Is this happening in some browser engines right now?
The Web Editing Working Group just discussed event order proposal when inserting replacement text such as text prediction, spell checker, etc.
.
I don't think this belongs in UIEvents. I believe the whole point of a separate InputEvents spec is so that it can own all of the inputType
-related information.
Since we're in the process of converting the UIEvents to be algorithmic (and eventually removing the "event ordering" tables), simply adding a note doesn't really fix the issue. Of course, since that conversion is ongoing (and the InputEvent
section has not been addressed yet), this is a bit challenging at the moment.
However, I think this is the perfect time to start addressing that. What would such an algorithm look like? And where would it live?
As I said above, if a very editing-specific action like "replace text" doesn't belong in the InputEvents spec, then I wonder why we have a separate spec. (And to be clear, I think it's very beneficial to have it as a separate spec).
So that brings us back to: what would this algorithm look like? My first stab (without thinking about any subtleties) is something like:
In order to perform an editing action on the target, <a>send an input event sequence</a>
with the event target and the inputType. Valid inputTypes are described in the
following table:
Table of valid inputTypes:
insertReplacementText
...
With the following algorithm added to UIEvents:
To <dfn>send an input event sequence</dfn>:
: Input
:: |target|, the {{EventTarget}} of the event
:: |inputType|, the string identifying the type of string being performed.
See [[InputEvents]].
: Output
:: None
1. Let |beforeevent| = <a>create a cancelable InputEvent</a> with "beforeinput",
|inputType|, |target|
1. Let |result| = <a>dispatch</a> |beforeevent| at |target|
1. If |result| is true, then do the following:
1. Let |event| = <a>create an InputEvent</a> with "input", |inputType|, |target|
1. <a>dispatch</a> |event| at |target|
1. Otherwise:
1. <handle canceled event>
Note that the other important part of this is having a description of how to handle the input event. I think this belongs in the InputEvents spec, although it may need refs to/from other specs.
To <dfn>handle the insertReplacementText input event</dfn>:
: Input
:: |target|, the {{EventTarget}} of the event (must be contenteditable?)
: Output
:: None
1. <describe the steps needed to update the DOM>
Does this sound like a reasonable starting point?
writingsuggestions and
spellcheck
are attributes that control UA-provided writing assistance such as text prediction and spell checker. When user accepts a suggestion/correction, wrong order of events fired might confuse online editors which may produce unexpected results.Here is a proposal that the order of events when inserting suggestions text:
The
beforeinput
event is cancelable. If it's cancelled, suggestion insertion should be aborted, and no input event is fired.Composition events are not necessary therefore shouldn't be fired when inserting suggestions/corrections.
The proposal also applies to other suggestion insertions such as auto-correct, etc.
The issue is also posted in WHATWG: https://github.com/whatwg/html/issues/10337