Re: <input type="number"> restricting user input to only valid characters

On Wed, 15 Jul 2009 06:51:24 -0400, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 15 Jul 2009, Michael A. Puls II wrote:
>> > > But, with "User agents must not allow the user to set the value to a
>> > > string that is not a valid floating point number", what does that
>> > > mean with the following?
>> > >
>> > > <input type="number">
>> > >
>> > > If the user types "abc", should .value return "abc" or "" or
>> > > "whatever the last valid value was"?
>> >
>> > It can return either "" or a valid number. It can never return "abc".
>>
>> O.K., but why a choice and not just a definite value?
>
> Because it's up to the user agent to decide what "abc" means. Maybe the
> user agent wants to support hex entry, or maybe "abc" is really "three"
> and the UA wants to support English input.

O.K., but then those would be examples of valid input in the case of the  
UA. I was just using "abc" as an example of something not being valid.  
But, good to know the UA can support hex if it wants.

> Maybe invalid inputs are
> ignored or maybe they are treated as a shorthand for "set the value to
> nothing".

O.K., so if the UA ignores invalid input, you'll get "" or a previously  
set valid number.

If the UA interprets invalid input as "", you'll get "".

So, O.K. No matter what the UA considers invalid or valid or whether it  
sets invalid input to "" or ignores it or only allows valid input, you'll  
either get a valid number or "" for the control's value. In that case, a  
value of "" would mean that "the control doesn't currently have a valid  
number set".

> Maybe the UA doesn't in fact accept keyboard entry at all, and
> requires that the user enter the number using an on-screen keypad. Or
> maybe it counts how many keys you press and uses that as the number, so
> "abc" is 3. Or maybe it just has spin-up and spin-down buttons. Or maybe
> it shows a dropdown of possible numbers to pick from.

Those are more cases of valid inputs according to the UA.

>> It'd be better to say that .value always returns "" when the value the
>> user enters isn't valid.
>
> Why does it matter? It doesn't affect interoperability.

Well, first, I just wanted to make sure that I understood things  
correctly. Thanks for your patience.

I also wanted to see how interoperable it is if you check .value for "" to  
see if the input in this case of type="number" is not valid. There's  
validity.valid and the individual others and you can check validity of the  
form, but if someone was just checking the value of the control to see if  
it's valid (I feel that might be likely), then I wanted to see how it'd  
work.

>> O.K., so what happens with
>>
>> <form action="test.py">
>>     <input name="x" type="number" value="1">
>> </form>
>>
>> when I type "abc" in the field and submit (assuming things are not  
>> validated
>> when submitting to prevent submission)?
>
> It either submits x=1 or x= (nothing). Or it doesn't allow you to type in
> "abc", so there's no way to answer the question. Or, if it is that  
> control
> I described that takes the number of keys entered as the number, it
> submits x=3. Or if the user agent supports the user setting the control  
> to
> hex, and the user has done so, it submits x=2748. So long as the user
> interface makes sense to the user, it doesn't really matter.

O.K. Thanks. I'm all set.

-- 
Michael

Received on Wednesday, 15 July 2009 12:06:31 UTC