Objective
Recent products need to do a lot of input boxes, the product wants the interactive effect is: Users can enter in English and Chinese, as the user input can real-time display the number of characters have been entered, when more than the number limit when the input box border red, while giving users the information.
This interaction does not sound like a problem, and there seems to be no difficulty in technology implementation. But when I realized that I encountered Chinese input method will have a hole.
What a pit, and see below ~ ~
Real-time monitoring of input box content length encountered pit usage oninput
events to monitor
oninput
There are 2 benefits to using this event:
When the user through the right key copy changes the input box content, may monitor hears;
This event is triggered only when the contents of the input box are changed, such as when the user presses the direction key, control
/ shift
and so on, when the control character keys is not triggered;
When you enter English characters or numbers, the effect is perfect, even 正常输入中文
when you have the perfect effect. But 非正常输入中文
there's a bug when you get there. What is the abnormal input? Look at this example diagram below:
See, in this type of Chinese input, in fact, the user has not entered the Chinese he wants to enter, but only a few pinyin, but the input
event was triggered, and the monitor to hear the input box value
is not d'd'd
only phonetic characters, but also includes a separate point. If the length of the input box is limited to no more than 5, the user will be prompted in the screenshot 字符长度超过限制!
. This kind of interactive effect is certainly not what the product wants.
Use onkeydown
/ onkeypress
/ onkeyup
events to monitor
The disadvantage of these events is that it is not possible to listen to the right button copy of the input, but whether there will be the input
same problem as the event?
I have done a few experiments, found that keydown
keyup
will encounter and input
the same problem, but keypress
there is no such problem, because in the Chinese input state, keypress
not trigger, not only you enter the pinyin process will not trigger, and so you select the Chinese to be entered as "right pair" Will not be triggered after that. When you enter "pair pair", you may have exceeded the character limit but could not give a 字符长度超过限制!
hint.
Compromise Solution
In order to achieve real-time monitoring content length, but also want to ensure that the Chinese input method without bugs, I toss for a long time finally found the Minister concubine can not do it! (If any hero finds it, be sure to tell me ~ ~).
So at the end of the sacrifice of the user experience, found a compromise way: when the input box loses focus (that is blur
), or when the user enters the ENTER key to detect the content length. Of course, if you find that the contents of the input box exceeds the limit, the cursor should be left in the input box to facilitate the user to modify.
Hey, when it comes to talking about 用户输入回车键时才进行内容长度的检测
the old pit.
How to detect the input enter in the input box
In fact, this is a very common interaction, such as the modification of the name of the user input after the support of the direct save, login to support the user input after entering the return direct login. But one of the pits to be careful is: **中文输入法下按回车键来输入英文字符**
.
The process of entering English characters by pressing ENTER under the Chinese input method is as follows:
For example, I want to enter the account to log in, my account is all in English, I am currently in the Chinese input method, but I am too lazy to switch input method, so I hit my account directly (all English characters), then Sogou input method to me prompted a large string of Chinese, and then I pressed a carriage return, input box on the input I want the English characters.
In this case, the user enters the ENTER key, but the user presses the ENTER key only to enter the English character in the Chinese input method, which is not the ENTER key we want to monitor. So how do you rule out the return enter in this case?
Generally listening for the ENTER key we will use keydown
events or keyup
events, the implementation code as shown below. So does both of these methods filter out the return key we don't want to monitor?
Method One: Use KeyDown event
Input.onkeydown = function (e) {
if (E.keycode =) {
//user input is enter
//Do related action
}
}
Method Two: Use KeyUp event
Input.onkeyup = function (e) {
if (E.keycode =) {
//user input is enter
//Do related action
}
}
After the test found that keydown
the use can be successfully filtered, but keyup
not use.
So let's see why?
is because in the keydown
event: The Chinese input method in the state entered the ENTER key, detection keyCode
for 229
instead of 13
; simply enter a carriage return, keyCode
is 13
.
And in the keyup
event: The Chinese input method in the state of input enter, the detection keyCode
is, 13
simply enter a carriage return, keyCode
is also 13
.
The following figure is the result of my printing in the console: (see code example here)
Conclusion
About the several events involved in the input box:keydown/keyup/keypress/input/change
View here: http://www.jb51.net/article/21237.htm