This regressed at some point, probably when rules-as-data-attributes where
introduced, since those are automatically parsed as JSON. For the unprocessed
attributes, the array brackets have to be removed.
Also fixes the milk demo, which specified rangelength as the message, instead of
minlength, which it actually uses.
Fixes#1087
The HTML5 draft defines, for type="number" inputs: "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."
If the constraint validation considers the input invalid, return false
as the value, instead of the empty string, for the number and digit
methods to output their messages.
This would break in browsers that support type="number", but not the
constraint validation API. I don't know of any existing browser where
that applies.
Fixes#858Fixes#922Closes#1093
Addresses an issue with the word count where smart quotes were not
removed, but the word count counted the words as the punctuation was not
removed.
Closes gh-811
The regex provided by the HTML5 spec allows email addresses without a top level
domain, like name@localhost. That makes the email2 method pointless.
Hopefully this is the last time the email methods ever has to be updated. At
least it will make bug triage easier: If you don't like the implementation,
report an issue against the HTML5 spec.
Fixes gh-828
Closes gh-753
Closes gh-739
Add aria-required tags to any of the data, static or class required elements.
Dynamic validation for rules added through the form.validate rules object do not get picked up till first run.
Added new test suite for testing the ARIA-invalid features
Also added a few minor fixes for typos in the QUnit scaffolding and
JSHint errors
Fix "%o has no name assigned [object HTMLInputElement]" errors in bypassValidation tests
In 1.10.0, min/max validation was supported for input type="text",
where min/max were interpreted as numbers. This means min/max
for date would not work: min="2012-02-13" was interpreted as min="Not a Number".
In 1.11.0, min/max were no longer converted to numbers. This means
min/max for dates worked, but min/max for numbers failed:
"50" < "150" < "1000" does not hold.
For an example, see http://jsbin.com/awokex/3
This commit makes the behaviour of min/max dependent on input type:
* input type=text (or not type attribute) has numeric min/max, as in 1.10.0
* input type=date has working min/max for type date;
on mobile browsers you also get a date picker,
plus the browser may reject invalid dates before
javascript gets a chance to complain.
* input type=number or range get numeric min/max,
plus numeric keypad or slider on mobile browsers,
plus browser may reject invalid input before javascript
gets a chance to complain
Allowing use of min/max with type=number/range/date is important
for mobile browsers, where the numeric keypad or date picker
make the input much easier to use than a generic text input field.
In this situation jquery-validate remains necessary to support
older browsers that do not do input validation based on type
and min/max.
For situations where numeric input should be validated by jquery
without giving the browser a chance to validate the input format,
input type=text in combination with min/max can be used, as in 1.10.0.
