tree 30fd04d23a51a43a70946a7af119e3de724e3761
parent c7ee4c0b1a9cd348ccf9ae789f42636c5fa77c7f
author Chris Rebert <github@chrisrebert.com> 1485009049 -0800
committer Josh Matthews <josh@joshmatthews.net> 1485009049 -0500

When type="number", HTMLInputElement.value uses strict parsing & doesn't clamp (#4593)

Per https://html.spec.whatwg.org/multipage/#number-state-(type=number):dom-input-value-2
HTMLInputElement.value uses the "value" mode when the <input> is of type="number".

Per https://html.spec.whatwg.org/multipage/#dom-input-value-value
> On setting, it must set the element's value to the new value, [...],
> invoke the *value sanitization algorithm*, [...]

Per https://html.spec.whatwg.org/multipage/#number-state-(type=number):value-sanitization-algorithm
> 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.

Per https://html.spec.whatwg.org/multipage/#valid-floating-point-number
the grammar for *valid floating-point number* does not allow:
* Trailing gibberish
* Leading plus signs
* Leading whitespace

So the 3 related tests' values are invalid and should get sanitized to the empty string.

And neither the *value sanitization algorithm* nor AFAICT any prose in
https://html.spec.whatwg.org/multipage/#number-state-(type=number)
requires number string values to get clamped/rounded
like the 2^53+1 test seems to expect.