(In reply to Steven Stavrakis from comment #46) > The input validity doesn't really help, since validation libraries use the value of the field to display error information to the user. I mean, it helps to some extent; it lets you distinguish between missing/empty value vs. invalid values. (Maybe it'd be nice to have a `input.displayValue` API if you want to print the value to the user, but for now at least, that API doesn't exist.) > The fact that an input can display a value (text) and simultaneously not have a value (empty string) is a strange and confusing dissonance. Sure, but this dissonance just falls naturally out of the fact that (a) this field is meant to represent a number (so there's an expectation for `.value` to be either empty or a valid number), and (b) numbers can be **textually made up of** tokens that are not in-and-of-themselves valid numbers; and so (c) there are intermediate states that users **must be allowed to type** but **do not represent valid numbers**. Those have to be displayed in the field as the users type them, but they can't be readable as numbers. (See bottom half of comment 36 for various strings that all browsers accept in numeric-input fields (e.g. `.e`) which are not valid numbers, but might need to be typed as part of entering or editing a valid number.) If you have a suggestion for how to better-handle these intermediate invalid states (e.g. via `input.displayValue` if that addresses your validation-library use-case), you can bring it up as a proposed edit to the HTML spec at https://github.com/whatwg/html/issues/ . Or if you or someone is up for trying to standardize an algorithm for allowing/disallowing certain characters (the main focus of this bug so far), that's great too, though it's likely quite complex and perhaps intractable to do so in the face of different numerical string-representations in different locales.
Bug 1398528 Comment 47 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Steven Stavrakis from comment #46) > The input validity doesn't really help, since validation libraries use the value of the field to display error information to the user. I mean, it helps to some extent; it lets you distinguish between missing/empty value vs. invalid values. (Maybe it'd be nice to have a `input.displayValue` API if you want to print the value to the user, but for now at least, that API doesn't exist.) > The fact that an input can display a value (text) and simultaneously not have a value (empty string) is a strange and confusing dissonance. Sure, but this dissonance just falls naturally out of the fact that (a) this field is meant to represent a number (so there's an expectation for `.value` to be either empty or a valid number), and (b) numbers can be **textually made up of** tokens that are not in-and-of-themselves valid numbers; and so (c) there are intermediate states that users **must be allowed to type** but **do not represent valid numbers**. Those have to be displayed in the field as the users type them, but they can't be readable as numbers. (See bottom half of comment 36 for various strings that all browsers accept in numeric-input fields (e.g. `.e`) which are not valid numbers, but might need to be typed as part of entering or editing a valid number.) If you have a suggestion for how to better-handle these intermediate invalid states (e.g. via a hypothetical `input.displayValue` API if that addresses your validation-library use-case), you can bring it up as a proposed edit to the HTML spec at https://github.com/whatwg/html/issues/ . Or if you or someone is up for trying to standardize an algorithm for allowing/disallowing certain characters (the main focus of this bug so far), that's great too, though it's likely quite complex and perhaps intractable to do so in the face of different numerical string-representations in different locales.
(In reply to Steven Stavrakis from comment #46) > The input validity doesn't really help, since validation libraries use the value of the field to display error information to the user. I mean, it helps to some extent; it lets you distinguish between missing/empty value vs. invalid values. (Maybe it'd be nice to have a `input.displayValue` API if you want to print the value to the user, but for now at least, that API doesn't exist.) > The fact that an input can display a value (text) and simultaneously not have a value (empty string) is a strange and confusing dissonance. Sure, but this dissonance just falls naturally out of the fact that (a) this field is meant to represent a number (so there's an expectation for `.value` to be either empty or a valid number), and (b) numbers can be **textually made up of** tokens that are not in-and-of-themselves valid numbers; and so (c) there are intermediate states that users **must be allowed to type** but **do not represent valid numbers**. Those have to be displayed in the field as the users type them, but they can't be readable as numbers. (See bottom half of comment 36 for various strings that all browsers accept in numeric-input fields (e.g. `.e`) which are not valid numbers, but might need to be typed as part of entering or editing a valid number.) If you have a suggestion for how to better-handle these intermediate invalid states (e.g. via a hypothetical `input.displayValue` API if that addresses your validation-library use-case), you can bring it up as a proposed edit to the HTML spec at https://github.com/whatwg/html/issues/ . Or if you or someone is up for trying to standardize an algorithm/set-of-rules for allowing/disallowing certain characters (the main focus of this bug so far), that's great too, though it's likely quite complex and perhaps intractable to do so in the face of different numerical string-representations in different locales.
(In reply to Steven Stavrakis from comment #46) > The input validity doesn't really help, since validation libraries use the value of the field to display error information to the user. I mean, it helps to some extent; it lets you distinguish between missing/empty value vs. invalid values. (Maybe it'd be nice to have a `input.displayValue` API if you want to print the value to the user, but for now at least, that API doesn't exist.) > The fact that an input can display a value (text) and simultaneously not have a value (empty string) is a strange and confusing dissonance. Sure, but this dissonance just falls naturally out of the fact that (a) this field is meant to represent a number (so there's an expectation for `.value` to be either empty or a valid number), and (b) numbers can be **textually made up of** tokens that are not in-and-of-themselves valid numbers; and so (c) there are intermediate states that users **must be allowed to type** but **do not represent valid numbers**. Those have to be displayed in the field as the users type them, but they can't be readable as numbers. (See bottom half of comment 36 for various strings that all browsers accept in numeric-input fields (e.g. `.e`) which are not valid numbers, but might need to be typed as part of entering or editing a valid number.) If you have a suggestion for how to better-handle these intermediate invalid states (e.g. via a hypothetical `input.displayValue` API if that addresses your validation-library use-case), you can bring it up as a proposed edit to the HTML spec at https://github.com/whatwg/html/issues/ . Or if you or someone is up for helping the WHATWG to standardize an algorithm/set-of-rules for allowing/disallowing certain characters (the main focus of this bug so far), that's great too, though it's likely quite complex and perhaps intractable to do so in the face of different numerical string-representations in different locales.