RFC: numeric input control localization

The value of a text input control is a string and it accepts any string that
fits into its width.  However, text input controls are used for other
purposes, the most prominent of which is to enter a number.  HTML provides
no explicit support numeric input controls so a text input control must be
used for that purpose.  Henceforth, the term "numeric input control" shall
denote a text input control with intended numeric semantics.

The script that uses the HTML DOM to control the presentation and content of
the page often needs the value of a numeric input control as a number for
validation, range checking and various calculations.  More precisely, the
page designer may need to:

*	Validate that the text value corresponds to a valid number; 
*	Validate that the numeric value lies within a range of permitted
values,
*	Calculate the amount due as the total of all numeric values (prices)

Neither of the applications above can be implemented within the current
specification.  All numeric values should be presented and accepted in a way
the end user understands, as specified in the language attribute 'lang'.  On
the other hand, the script that controls the page is not expected to know
anything about how the user's locale formats numbers, as Richard
<http://www.icu-project.org/docs/papers/internationalization_support_for_jav
ascript.html>  Gillam explains:

The approach we took for the core language was as minimalistic as we could
reasonably make it. We added no more than the basic functionality, eschewing
all frills. We also took steps to ensure that we imposed no more of an
implementation burden on implementors than was absolutely necessary. In
support of that philosophy, we designed everything so that implementors
could use any facilities available to them from their host environments.
They could also declare that they support only a single locale and hard-code
its behavior, or just fall back on the locale-independent algorithms. This
could introduce portability problems, but the idea was that these functions
were really only for producing user output and other things like that. In
other words, we wanted everything to produce a "reasonable result" for
whatever locale the user was using. That was it.

Considering the circumstances described above, we inevitably arrive at a
conclusion that the burden of handling numeric values in the user interface
should be imposed on the host and not on the script or the script engine.
This requirement may be fulfilled by adding a numeric input control type to
the HTML language specification where its value attribute type would be
numeric and not text; however, it is not a pure extension because an
outdated user agent has no idea that it should treat a numeric input control
as a text input control.  Moreover, the controlling script might be
interested how the numeric value was entered, which information would be
inaccessible, and a strongly typed script could encounter a value of an
unexpected type and fail.

My suggestion is to add the following attribute to the interface
HTMLInputElement:

numeric of type double

When the type attribute of the element has the value "text", this represents
the current numeric value of the corresponding form control, in an
interactive user agent, according to the language attribute pertinent to the
control. Changing this attribute changes the contents of the form control by
means of system-dependent and locale-dependent rules, but does not change
the value of the HTML value attribute of the element.

Please consider this suggestion for further development.

Yours sincerely,

Christopher Yeleighton