1194812 - Prevent users typing any character into <input type="number"> that would not be a valid part of a number (ignore those characters)

Status: RESOLVED DUPLICATE of bug 1398528

(Core :: Layout: Form Controls, defect)

Description

[root]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150702232110

Steps to reproduce:

Enter a string on number type field, then try to get it later


Actual results:

You obtain an empty result.

Fiddle: http://jsfiddle.net/qyd4geow/


Expected results:

You shouldn't be able to enter strings on a number type, as it is confusing for the inexperienced user, and causes troubles on javascript based validations.

Examples:
https://github.com/igorescobar/jQuery-Mask-Plugin/issues/201
https://github.com/guillaumepotier/Parsley.js/issues/751

Comment 1

[Boris Zbarsky [:bzbarsky]]

> You shouldn't be able to enter strings on a number type, as it is confusing for the
> inexperienced user

So is hitting a key and nothing happening, no?  Add to that that the set of allowed keystrokes would be locale-dependent (e.g. '.' vs ','), and users would get quite confused.

Comment 2

[root]

(In reply to Boris Zbarsky [:bz] from comment #1)
> So is hitting a key and nothing happening, no?  Add to that that the set of
> allowed keystrokes would be locale-dependent (e.g. '.' vs ','), and users
> would get quite confused.

Current standard does not use locale-dependent floating points (http://www.w3.org/TR/html-markup/input.number.html), so it's not a problem to consider.

On my consideration, to allow writing something that is not being processed as shown in screen is quite more confusing.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Current standard does not use locale-dependent floating points

The standard doesn't define the processing of user input at all here.  In practice, user input can use locale-dependent floting-point numbers.

Comment 4

[Jonathan Watt [:jwatt]]

(In reply to Boris Zbarsky [:bz] from comment #1)
> So is hitting a key and nothing happening, no?  Add to that that the set of
> allowed keystrokes would be locale-dependent (e.g. '.' vs ','), and users
> would get quite confused.

And many different number characters of course: http://unicode.org/charts/

FWIW Chrome now ignores any attempt by a user to type or paste in characters that aren't one of the characters used in HTML's "valid floating point number" format or that aren't a valid digit or decimal separator in the user's system locale.

Comment 6

[oliver.winkler]

So, 3 years+ with such a bug...
Quote of the standard: "User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number."
And why is the ticket 1342477, with major priority closed without adjusting the priority here?

Comment 8

[Jonathan Watt [:jwatt]]

Technically this bug was filed first, but there's more useful discussion over in bug 1398528 at this point. So I'm duping this one to bug 1398528.