W3C home > Mailing lists > Public > public-html@w3.org > July 2009

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

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Wed, 15 Jul 2009 04:52:41 -0400
To: "Ian Hickson" <ian@hixie.ch>
Cc: public-html@w3.org
Message-ID: <op.uw3pl1vu1ejg13@sandra-svwliu01>
On Tue, 14 Jul 2009 19:20:15 -0400, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 14 Jul 2009, Michael A. Puls II wrote:
>> On Tue, 14 Jul 2009 01:29:43 -0400, Ian Hickson <ian@hixie.ch> wrote:
>> > On Fri, 19 Jun 2009, Michael A. Puls II wrote:
>> > >
>> > > With <input type="number">, if a user enters "abc" for example, the
>> > > specs says to handle that as if the value is an empty string.
>> >
>> > No, the spec doesn't say how to handle it. That's a user interface  
>> issue,
>> > out of scope of the spec.
>> >
>> > It does say, however, that:
>> >
>> > # User agents must not allow the user to set the value to a string  
>> that is
>> > # not a valid floating point number.
>> >
>> > ...so if the user does enter "abc", it won't affect the element's  
>> value.
>>
>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#number-state>
>> I do see "User agents must not allow the user to set the value to a  
>> string
>> that is not a valid floating point number".
>>
>> But, I also see "The value sanitization algorithm is as follows: If the  
>> value
>> of the element is not a valid floating point number, then set it to the  
>> empty
>> string instead.", which is where I got the empty string part from.
>
> What the user enters (or sees!) is not the value. The value is the
> underlying data that is then converted for display, and the data the user
> enters is converted back to the value. The value sanitization algorithm  
> is
> never applied to user input by the spec.

O.K.

>> 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?

If you type "abc" and .value can return either "" or a valid number, then  
that implies that if the underlying value has not been set to a valid  
number yet and you type "abc", .value will return "", otherwise if you  
type "abc", it'll return the valid number that was stored in the  
underlying value before you type "abc".

For example:

<input type="number"> and you type "abc" - .value would return ""
<input type="number" value="1"> and you type "abc" - .value would return 1.

It'd be better to say that .value always returns "" when the value the  
user enters isn't valid.

<input type="number"> and you type "abc" - .value would return ""
<input type="number" value="1"> and you type "abc" - .value would return  
"".

That seems to be what Opera does in its WF2 implementation of it at least.

>> Or, is "abc" only converted to "" when submitting?
>
> It's converted to "" whenever the value sanitization algorithm is
> invoked, which is only when the element is created or when it changes
> type.

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)? I get "test.py?x=",  
right? (which means the "abc" value I entered was converted/interpreted as  
"")

Or, are you saying that I should get "test.py?x=1" because the "abc" I  
typed was invalid and therefore didn't change the underlying value?

I'm almost certain it's the former, which would mean:

'Whenever the user inputs a value in the field that is not a valid number,  
the value that the .value getter returns and the value that's submitted  
will be ""'

-- 
Michael
Received on Wednesday, 15 July 2009 08:53:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:05 UTC