[whatwg] typeMismatch for type=number (Re: Input color state: type mismatch)

TAMURA, Kent tkent at chromium.org
Thu Jul 22 08:10:16 PDT 2010

On Sat, Apr 3, 2010 at 06:37, Ian Hickson <ian at hixie.ch> wrote:

> On Sat, 3 Apr 2010, TAMURA, Kent wrote:
> >
> > I found type=number also had no typeMismatch. If a user wants to type a
> > negative value, he types '-' first.  This state should make typeMismatch
> > true because '-' is not a valid floating point number.

> The user agent shouldn't update the value until the input is a valid
> number. ("User agents must not allow the user to set the value to a string
> that is not a valid floating point number.")

I don't accept this behavior.  Suppose that a user type "-" to an empty
<input type=number>, then press ENTER to submit the form. As per the current
specification, UA should send an empty value for the number control even
though the number control has a visible string.  The user doesn't expect a
value different from the visible value is sent.  This is very confusing.

In such case, UA should prevent the form submission and show a validation
message for typeCheck.

Software Engineer, Google

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100723/d10dcc65/attachment-0001.htm>

More information about the whatwg mailing list