-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
beforeInput: Unify "deleteContent" and "deleteComposedCharacter" #118
Comments
@yosinch Right. Your argument seems logical. But for some reason we decided to split it into two at the F2F meeting in Paris last year. I don't exactly recall why, but we should look at the protocol from back then. |
Just to clarify UA should only fire For example in Chinese IME:
And also @johanneswilm do you mind pointing me to the discussion in F2F? I agree with @yosinch that having both is redundant since we already have Thanks! |
@choniong I found the resolution [1]. And it does make sense: We were mainly looking at cE=typing. cE=typing is a contenteditable mode where the browser would only handle typing new characters and selection changes. It will not handle deletion of content. The exception here being during composition. During composition, the browser would have a default behavior both for insertion and deletion of characters, because at the time we understood the relationship of IME and browser as making it impossible for the browser to hinder IME input. So given that the deletion of the compositionstring (in point 5) is something that cannot be canceled and will ave to have a Dom changing action on cE=typing, I would say this has to be deleteComposedCharacter. [1] "RESOLUTION: : We |
That is correct. If we are just deleting characters, outside the IME, this shouldn't matter.
This is where the entire composition string is being deleted and then reinserted, correct? So this would be two different events then (deleteComposedCharacter and insertText) of which the second should be cancelable.
That is correct. It doesn't matter how the character was inserted originally. What matters here is that the entire action takes places outside the IME, which means the event can be canceled and the JS can do something alternative without breaking the browser.In the case of cE=typing, the browser will not do anything by default, so it relied entirely on a JS implementation of an editor.
The alternatives seem to be to say: A) deleteCharacter can be canceled in all types of cE, and it has no default action in cE=typing, EXCEPT if it is triggered with isComposing=true. If it it is triggered with isComposing=true, then it cannot be canceled and it does have a default action in cE=typing. or: B) deleteCharacter can be canceled in all types of cE and has no default action in cE=typing. deleteComposedCharacter cannot be canceled in any type of cE and has a default action defined in cE=typing. On the JavaScript side of things it doesn't really matter if we choose A or B. So if this doesn't go against internal conventions for how your browser code is written, it probably makes more sense to use A (which is what you guys propose). The only issue I have is that the event definition in the ui events spec now says that the event is always cancelable whereas we really need to say that it is not cancelable under certain circumstances. |
Thanks for the detailed explanation! I still got some questions about IME, will probably create a separate issue. |
Ok, it seems like this proposal has been retracted. Please reopen if this assumption is incorrect. |
Having both "deleteContent" and "deleteComposedCharacter" is redundant. Web author can know whether text composition is ongoing or not.
If in "text composition" and out of "text composition" is important, we should also have "insertComposedCharacter" too. Note: we should have "insertComposedText" instead of "insertComposedCharacter", since IME can insert multiple character by one user action e.g. ASCII emoji, (^_^), auto correction, auto expanding of abbreviation etc.
The text was updated successfully, but these errors were encountered: