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

Wed Jun 8 17:43:59 PDT 2011

(This thread was cross-posted to several lists. To mitigate further thread 
fragmentation, I've only cc'ed the whatwg list on this reply.)

On Fri, 25 Feb 2011, Makoto Kato wrote:
> 
> This is simple sample.  This behavior is different on all web browsers 
> when input element has composition/preedit string for IME.
> 
> If input element has composition string by IME, should it cancel 
> composition string and set value by script?  Or should it cancel setting 
> value since it has composition string?
> 
> <script>
> function setvalue() {
>   document.getElementById('test').value = "replaced";
> }
> </script>
> <body onload="setTimeout('setvalue()',5000)">
> <input type="text" id="test"/>
> </body>

Well the value should definitely get set, per spec. Whether the IME should 
reset state is a UI issue, so the spec doesn't address that.

On Tue, 1 Mar 2011, Makoto Kato wrote:
>
> On Safari 5, even if textbox has IME composition string, text into 
> textbox can be replaced by DOM/script.  But other browser's behaviors 
> are different, and this is no specification when textbox has composition 
> string.  Although IE, Chrome and Opera keep composition string after 
> value is replaced by DOM, each behavior is different.
> 
> This is the result for this test on each browsers.  When textbox has IME 
> composition string such as ABCDEFG, then script (textbox.value = "123";) 
> is called, textbox becomes...
> 
> 1. "123ABCDEFG" (ABCDEFG keeps composition state and caret is after G).
> 2. "123" (composition string is removed).
> 3. "ABCDEFG" (ABCDEFG keeps composition state and caret is after G).
> 
> Which behavior is right?  1 is Opera 11, 2 is Safari 5, and 3 is Chrome 
> 10 and IE9.

Either is right, so long as textbox.value == "123" at this point.

On Thu, 3 Mar 2011, Makoto Kato wrote:
> 
> It is confused that each Web browser is different behavior for this. 
> This is not good as interoperability.

How does it impact interoperability?

On Mon, 28 Feb 2011, Kang-Hao (Kenny) Lu wrote:
> (11/02/25 15:16), Makoto Kato wrote:
> >
> > This is simple sample.  This behavior is different on all web browsers 
> > when input element has composition/preedit string for IME.
> 
> A relevant question here, I think, is where the cursor should go when 
> the value of the text box is set by script. For Safari5, it always goes 
> to the end when the value is set. For FF4.0b11, the cursor stays in 
> previous position when the value to be set is the same and goes to the 
> end when the value is different. Is this a known incompatibility? I find 
> the behavior of FF quite strange.
> 
> > If input element has composition string by IME, should it cancel 
> > composition string and set value by script?  Or should it cancel 
> > setting value since it has composition string?
> 
> What makes sense to me is:
> 1. the cursor always goes to the end
> 2. the composition string goes with the cursor, which should not change.
> 
> But I am not sure whether this is the right way to go.

I've specced what should happen to the cursor and selection, though only 
as a "should". I haven't specced what should happen with IME since, as 
mentioned above, it seems like this is just a UI issue that doesn't affect 
interop (you can't detect the IME state unlike the selection state, for 
example).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'