Skip to content
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

Closed
yosinch opened this issue Mar 16, 2016 · 6 comments
Closed

beforeInput: Unify "deleteContent" and "deleteComposedCharacter" #118

yosinch opened this issue Mar 16, 2016 · 6 comments

Comments

@yosinch
Copy link

yosinch commented Mar 16, 2016

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.

@johanneswilm
Copy link
Contributor

@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.

@chong-z
Copy link

chong-z commented Apr 13, 2016

Just to clarify UA should only fire deleteComposedCharacter during composition, but not for the deletion of final 'ComposedCharacter' after composition?

For example in Chinese IME:

  1. Press 'n', (fire insertText with data='n')
  2. Press 'u', (fire insertText with data='u')
  3. Press 'backspace', (fire deleteComposedCharacter because it's still during composition)
  4. Press 'i', (fire insertText with data='i')
  5. Press 'space' to accept, (fire insertText|replaceContent with data='你')
  6. Press 'backspace', (fire deleteContent because it's outside composition even if the character to be deleted is a composed character)

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 isComposing

Thanks!

@johanneswilm
Copy link
Contributor

@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
will have typing with compositionstart (cancelable) when you
can set a selection point, then a series on non cancelable
beforeinputs to replace text, and two kinds of delete events -
one inside composition not cancelable, and a "normal" one to be
handled by the application"

https://www.w3.org/2015/08/23-webapps-minutes.html

@johanneswilm
Copy link
Contributor

Just to clarify UA should only fire deleteComposedCharacter during composition, but not for the deletion of final 'ComposedCharacter' after composition?

That is correct. If we are just deleting characters, outside the IME, this shouldn't matter.

For example in Chinese IME:

  1. Press 'n', (fire insertText with data='n')
  2. Press 'u', (fire insertText with data='u')
  3. Press 'backspace', (fire deleteComposedCharacter because it's still during composition)
  4. Press 'i', (fire insertText with data='i')
  5. Press 'space' to accept, (fire insertText|replaceContent with data='你')

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.

  1. Press 'backspace', (fire deleteContent because it's outside composition even if the character to be deleted is a composed character)

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.

I agree with @yosinch that having both is redundant since we already have isComposing

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.

@chong-z
Copy link

chong-z commented Apr 13, 2016

Thanks for the detailed explanation!
Now I get the idea of the design and yes having both deleteContent and deleteComposedCharacter is much clearer to the web developers.

I still got some questions about IME, will probably create a separate issue.
Thanks!

@johanneswilm
Copy link
Contributor

Ok, it seems like this proposal has been retracted. Please reopen if this assumption is incorrect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants