[whatwg] set input.value when input element has composition string

On Thu, Mar 3, 2011 at 7:47 PM, Makoto Kato <m_kato at ga2.so-net.ne.jp> wrote:

> Hi, Niwa-san.
>
> On 2011/03/02 15:30, Ryosuke Niwa wrote:
>
>> You must have tested Chrome improperly.  We currently have a bug in
>> Chrome.  To see the bug, open the attached test and type "nihao" with
>> Chinese IME on Windows or Mac.  Then press down array key.  The text is
>> replaced by henhao but "henha" is still marked and looks as if I'm
>> compositing "henha" but if I continue to type "ma" still with IME, then I
>> observe that "henhaomao" is shown inside the input element.  Once this bug
>> is fixed, Chrome's behavior should match that of Safari 5.
>>
>
> Do you think Safari's way (ex. 2) is right?
>

In short, yes.

It is confused that each Web browser is different behavior for this . This
> is not good as interoperability. So I would like to decide the right
> behavior/specification when textbox.value = 'x'; that it has composition
> string.
>
> Also, some people says that it should not be canceled/removed even if value
> is changed by DOM.  Because composition string is un-committed string.


It seems that the "correct" behavior depends on the semantics.

Say I have typed a text "??", then I decided to add ? between ? and ? so I
put the caret / insertion point between the two and start typing "men" on
IME.  At this point website randomly replaces the entire value by "Hello".
 In that case, as a user, I wouldn't expect to have my uncommitted string
"men" after "Hello" because semantically speaking, my greeting message in
Chinese has entirely been replaced by one in English.  There's no point in
adding "men" at this point.

On the other hand, if I had just typed "?" and website replaced the value by
"??" as I typed "hao" on IME, then having the uncommitted text after "??"
makes sense and I'd like to keep the text because then I can just commit my
text to obtain "???".

- Ryosuke

Received on Thursday, 3 March 2011 03:28:05 UTC