input[type=date] fails validation regardless of what rules exist

[kapowaz]

If you include an input with a type of date in your form, and validate the rest of the form, then values which are valid for that type of input (the spec for which mandates an ISO date format of YYYY-MM-DD) will be flagged as invalid. Infuriatingly, it appears impossible to bypass this, since jquery-validation always tries to validate this type of input regardless of what rules you've specified. Attempting to forcibly remove the rule for that element (with $('input[type=date]').rules('remove'), say) initially appears to have succeeded, but querying the rules shows that it remains in effect.

The upshot of this is that browsers that now support input[type=date] have to be given a downgraded experience (either a series of selects, or an input[type=text]) rather than the new native control (i.e. Mobile Safari/iOS 5.0), or sacrifice jQuery validation.

[jzaefferer]

Before letting the fury take over, please consider that type=date didn't exist back in 2006, when the plugin and most of the built-in rules were initially written.

With that in mind, there are a few options: For a simple workaround, just remove the rule within your setup:

delete $.validator.methods.date

Once that is done (after including the plugin), it will ignore the type, as that won't match any known method anymore.

To avoid the issue in the future, a rename or refactor might be in order. Renaming would avoid the overlap, refactor might help match what type=date is specified to expect.

Either way, the built-in date methods are very simple and limited. Using a library like Globalization would provide much better validation, but so far interest in better date validation was pretty much non-existant.

Let me know if the workaround helps, and what you think on the broader issue. Thanks for reporting!

[sammyhk]

Hi, I also encounted this issue. I think we can delete $.validator.methods.date and enhance $.validator.methods.dateISO to support the date validation

[kapowaz]

Thanks for the quick response, Jörn — and apologies if I came across a little too furious! The suggested workaround does indeed appear to do the job, thanks. I second sammyhk's suggestion; refactoring the date validation method to centre on the ISO format that input[type=date] requires sounds like a good idea to me.

This is an area that definitely will need keeping an eye on though, as different browsers have different implementations of datepickers (iOS 5 gives us the fruit machine spinner for all three components; Opera presents a calendar picker, and Safari (desktop) gives a very basic spinbox a la input[type=number]). Some browsers ‘implement’ date inputs, but don't actually do anything with them (they're treated identically to text inputs, but the browser acknowledges it understands that type, unlike input[type=foo]), so they permit free text entry (which naturally is invalid).

Also, in the case of the iOS 5 picker, what it displays in the browser view is not an ISO date (it takes the format Jan 17, 2012 — but the value inside the DOM is still an ISO one). I'm not sure if this will necessarily impact things like client-side validation, but it's one to watch out for lest we start validating against a date format being used purely for presentation.

[emilras]

Thanks for the work around - very helpfull!

[jonwingfield]

Has this issue been resolved? Do you guys need a pull request?

[jzaefferer]

@jonwingfield I'd like to spend more time on this plugin, but can't really. But a PR would be much closer to something I could land with a little less effort. The problem for now though is the design: How can we deal with native inputs conflicting with custom validation? Is the solution really to kill the date method? Beyond the conflict that method sucks anyway, so yeah, that's probably a good idea. What are the alternatives? Beyond the occasional bug report, I have no clue how people actually use the plugin and available methods.

[jonwingfield]

@jzaefferer Yes, I'm concerned about backwards compatibility with this change. I'll see what I can whip up and test in multiple browsers, send a pull request, and we can collaborate from there on whether it's a good idea or not.

[Vassi]

I can confirm that this is still an issue, which is unfortunate. Another workaround (if you need to validate dates anyway except for the date fields) is to apply ignore: "input[type='date']" to your validate options, which prevents them from coming up at all.

[jzaefferer]

Replacing with #1063