Closed notwaldorf closed 8 years ago
This change looks good to me. However, it definitely deserves a test for the condition where the browser's validity pre-empts our validity.
Bump for test.
Sorry, it's been low priority. Will get to it soon!
@cdata added a test. PTAL.
LGTM :+1:
LGTM2. Nice work on getting the tests added :cookie:
Landed via https://github.com/PolymerElements/iron-input/commit/bd5ce7131245ca39c759ceeb178a933fdd5b5528 and https://github.com/PolymerElements/iron-input/commit/1a6df3d8387a5c64a0392d0d12cf681f82225021.
(Btw, if y'all have a preference on either waiting for squash or manually having the reviewers squash can do either for other PRs)
Fixes https://github.com/PolymerElements/iron-input/issues/46
The issue was that if you type invalid things (like ---) in
type="number
, the browser sets thevalue
to "". Since we were first checkingrequired
and thevalue
, we actually returnedtrue
in this case.I've rejiggered the function to:
required
check, and ask thevalidator
if we have one.It used to be that the validator was checked first. First of all, I'm not sure what it means to have both a
validator
and a browser validation. Take something like<input pattern="[1-9]*" validator="value-is-exactly-equal-to-cat">
; should the string "cat" be valid? not be valid? who knows. Second, I am not even sure that's right, since inside a form, for example, the form will only look at the browser validity anyway and ignore the validator, so technically browser rules all. I am not opposed to leaving it the original way though.Here's the kicker: I literally cannot add a test for this. Because security, you can't simulate typing inside and
input
, and becausetype=number
is πππ , it does not let you programmatically set it to an invalid value. ππ«