Kendo-ui-core: The masked text box does not skip hard-coded numerics

[petyosi]

Dojo:

http://dojo.telerik.com/aGela

Focus the input and press "3". Instead of accepting the number as the existing symbol, it fills in the first available mask position with 3, resulting in 3-33. This is inconsistent with other hard-coded symbols, like the dash, for example.

[Xizario]

Some further notes. Let say we have mask like:
mask: "\\a1\\a1---&&&" which results in a1a1---___
Typing a , 1, or -, behaves the same way. It jumps the literals, and places the new character at it's first possible place. So it is consistent for all parts.

The inconsistency in the original Dojo is because there is no part that accepts dash, and it is used only as hard-coded literal. Here is example version with the opposite behavior.

[petyosi]

@Xizario - What would be the desired behavior? Do you think that we should keep it as-is? I find the case rather esoteric, and to be honest I am not sure what's a good real-world use-case we can examine.

[Xizario]

I think both are equally correct. But my sense tell me they have different usage, depending on how many characters the user is wheeling to enter. And on that how obvious is what can be edited and what not.

Jumping over the literals would be more desirable if they many and different literals. Let say we have and example where user needs to fill up his phone number, but country and operator code are predefined:
(+359 88_) ______ .

If the cursor is at the beginning, pressing anything, moves it to the first possible part. Typing a valid char, moves and types at the same time. So it does not matter if you type 1,2,3,4,5 ... you get similar result.
So I see two ways of changing the current behavior, but both are not looking good:
1) skip the part if match the next literal: making inconsistent behavior, and blocks the user from entering, until he actually navigates or types everything.
2) skip all literals if not match any of them: jumping to the first possible, would be even more inconsistent, because we get different result if pressing '8' or '7'
3) some other option, that I am missing..

And yet there is always the second use case.
An user is asked to fill up a color, and he get such input:
rgb(2__,2__,2__)
I would expect typing "255" to result in rgb(255,2__,2__) and not rgb(225,25_,2__), and I would be disappointed, yet at the same time I will not want to type 'r' , 'g' and 'b' to get there.

See in the second example it is not obvious that "2" is hard coded. It looks just like predefined value that can be changed, not like hard coded one. End user himself will not be sure what would happen, until he try to type something.

Bottom line:
Personally I prefer hard-coded parts to be outside the input. And if they are multiple parts that can be edited, there should be multiple inputs.

[petyosi]

Good analysis. I think that we may look into treating formatting chars ((._-)) and predefined parts of the value (alphanumerics) in a different manner. Since there are valid cases for both behaviors for the alphanumerics, we can consider a configuration option. I will leave the decision up to you.

[ggkrustev]

Guys, what do you think about to move the caret at the first empty placeholder '_'. This will be done on focus and LEFT/RIGHT keys will move you only on the empty places. Wouldn't this help to reduce the confusion about the static chars? Could we consider such an approach?

[Xizario]

But the (._-) characters can be as well free chars (the & mask part) http://dojo.telerik.com/aGela/6 so treating them differently does not seem right to me. Currently the only exception is typing the prompt char.

@ggkrustev. Placing the focus on first editable part sounds good to me. But it is code overkill, and heavy browser depended. Focus, click, mouse over, touch, tab, drag and selection are behaving differently in all browsers. And can cause lots of troubles, I would personally prefer to fix all current issues, then go further with that.

In both cases the learning curve is very short, and it is easy to enter data into second masked textbox or retyping the current. So for further consideration and decision we would need more real data and feedback. Do they show one time only input for new users or they use them on regular basis. Do they get complains about their forms, etc.

[petyosi]

After some thought, I think that we can leave the current behavior as-is and move on. It is not horribly broken, and works for a known set of cases. @Xizario - if you can come up with an obvious and easy solution, go for it. If not, let's close with won't fix.

[nlazarov]

The two cases seems to be dependent on how the user wishes to fill in the data in the masked input.

If we go with the original mask 3-30 and the user types 3 I could want the masked to by typed through and the caret should be at 3|-3_. But at the same time another user would be annoyed by this behavior - How come a valid character is not entered in the input?.

We could come up with an option for this behavior - something like typableMask, but I don't think that allowing this scenario would add any real value to the MaskedTextBox, although without real data on our customer's view this is only my opinion.

Finally I don't think this is a bug, but rather a scenario not implemented - maybe label it improvement. Still I will mark this issue as won't fix. We could revisit it if we have enough information if customers really want this functionality as part of the widget.