为什么此输入有效 [英] Why is this input valid

问题描述

使用 input.validity.valid ，为什么我的在这种情况下，数字输入有效值 0。？

Using input.validity.valid, why does my number input return valid for the value 0. in this scenario?

<input type="number" min="1" max="999" step="1" value="0." id="one" /> <!--Valid??-->
<input type="number" min="1" max="999" step="1" value="0.0" id="two" /> <!--fine-->
<input type="number" min="1" max="999" step="1" value="0" id="three" /> <!--fine-->

Chrome 37.0.2062.103 m

Chrome 37.0.2062.103 m

< a href =http://jsfiddle.net/3rL8q5t9/ =noreferrer> jsFiddle

编辑

奇怪的是，任何带有句号结尾的负数也会打破验证：

Oddly, any negative number with a period at the end also breaks the validation:

<input type="number" min="1" max="999" step="1" value="-14." id="one" />

jsFiddle

推荐答案

这里实际上有两个答案：

There are actually two answers here:

1. Chrome中存在一个错误，这意味着当您在输入字段中输入/设置时， 0。之类的值无法正确验证。


2. 如果在HTML标记中设置了无效值，浏览器必须忽略它并将值设置为空字符串，除非字段标记为<$ c，否则该字符串被认为是有效的$ c>必需。

1. there's a bug in Chrome which means a value like 0. is not validated correctly when you enter/set it in an input field.
2. if you set an invalid value in the HTML markup, the browser is required to ignore it and set the value to the empty string, which is considered valid unless the field is marked required.

严格来说，这是第一个导致你的行为的人看，因为它阻止＃2发生，但如果错误在Chrome中得到修复，那么问题就在于（即只处理初始标记，而不是任何后续用户交互），＃2将适用。

Strictly speaking, it is the first one that is causing the behaviour you are seeing, because it stops #2 from ever happening, but if the bug were fixed in Chrome then as the question stands (i.e. only dealing with the initial markup, not any subsequent user interaction), #2 would apply.

同样值得注意的是，＃2是导致类似（但不完全相同）行为的原因Firefox。

It's also worth noting that #2 is what causes the similar (but not identical) behaviour in Firefox.

＃1的原因是Chrome在其 rangeUnderflow 检测中使用了不同的解析算法 badInput 检测。

The reason for #1 is that Chrome is using different parsing algorithms in its rangeUnderflow detection and its badInput detection.

rangeUnderflow 使用 Decimal :: fromString（...） 返回 NaN 如果输入以结尾。导致 rangeUnderflow 返回 false ：

rangeUnderflow uses Decimal::fromString(...) which returns NaN if the input ends in a . causing rangeUnderflow to returnfalse:

if (!numericValue.isFinite())
   return false;

相比之下， badInput 使用 StringToDoubleConverter :: StringToDouble（...） 基本上忽略尾随的。所以输入不被认为是'坏'。

In contrast, badInput uses StringToDoubleConverter::StringToDouble(...) which basically ignores a trailing . so the input is not considered 'bad'.

根据< a href =http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-floating-point-number =nofollow>规范 ：

字符串是有效浮点数，如果它包含：

1. 可选，U + 0 02D HYPHEN-MINUS字符（ - ）。


2. 以下一个或两个，按给定的顺序：
   

1. Optionally, a U+002D HYPHEN-MINUS character (-).
2. One or both of the following, in the given order:

1. 一系列的一个或更多ASCII数字。

1. A series of one or more ASCII digits.

1. 单个U + 002E FULL STOP字符（。）。


2. A一个或多个ASCII数字的系列。

注意2.2.2不是可选的 - 即如果你有一个。，你必须有数字。

Note that 2.2.2 is not optional - i.e if you have a . you must have digits after it.

所以这是 badInput 这是不正确的。 （如果Chrome至少将 0。视为有效，则会检测到 rangeUnderflow ）

So it's the badInput that's incorrect. (If Chrome was at least consistent about treating 0. as valid, the rangeUnderflow would then have been detected)

但如果/当他们修复Chrome中的错误时，问题中的HTML会显示 显示为有效。为什么？

But if/when they fix the bug in Chrome, with the HTML in the question, it will still show as valid. Why?

例如，如果在HTML中设置 value =aaa。输入仍将显示为有效，即使 aaa 会导致 badInput 为 true 。

Take for example if you set value="aaa" in the HTML. The input will still show as valid, even though aaa would cause badInput to be true.

这是因为在解析/呈现页面时，Chrome会对属性值运行值清理算法。当它看到的值不是有效浮点数，它必须根据规范。除非输入标记为 required ，否则空字符串被视为有效。 Chrome目前不会出现 value =0。，因为它（错误地）传递了值清理算法。但是，如果/当他们修复Chrome中的错误时，就会发生这种情况。

This is because while parsing/rendering the page, Chrome runs a value sanitization algorithm on the attribute value. When it sees a value that is not a valid floating point number, it must set the input's value to the empty string as required by the spec. And the empty string is considered valid unless the input is marked required. This currently doesn't occur in Chrome for value="0." because it (incorrectly) passes the value sanitization algorithm. However, if/when they fix the bug in Chrome, this is what you would expect to happen.

如果您实际输入 aaa 进入输入后，它将显示为无效，即 badInput === true 。同样，在Firefox和Chrome中，如果/当他们修复错误时，如果你在字段中键入 0。，它将给出 badInput == = true 因此有效=== false 。

If you actually type aaa into the input, it will then show as invalid, i.e. badInput===true. Similarly, in Firefox, and in Chrome if/when they fix the bug, if you type 0. into the field, it will give badInput===true and therefore valid===false.

这篇关于为什么此输入有效的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！