appropriate jQuery events for input validation

[sneakyimp]

I'm wondering which jQuery events to use for validating form inputs as a user operates on a form. I'd love to just use the change event, but this is apparently only fired for text inputs or textareas when they lose focus -- which is inadequate for validate-as-you-type functionality. Additionally, some events respond to mouse events and also to keyboard events, autocompletion, etc. For example a select input responds to user keystrokes.

Can anyone help me identify approprate event types for the various inputs?
input, type=text = keypress ?
textarea = keypress?
input, type=radio = change? keyup?
input, type=checkbox = change? keyup?
* select = change? keyup?

I've seen two suggested approaches. One is to bind a handling function to a 'salad' of events:

$(selector).bind("propertychange keyup input paste blur", { put data here if necessary }, Selector_Dirty_Handling_Function_Name)

Another is to write code to take a snapshot of the form and its values and then use setInterval (or possibly some event salad) to monitor the form and trigger one's own sort of event when something's value changes.

Any input would be much appreciated.

[Bonesnap]

I think part of it depends how "quickly" you want to validate. What I mean by that is if you want to validate as the user is using the form, or upon submission. Traditionally I do it on submission because it really simplifies the whole thing and keeps code to a minimum.

For validating as the user types, myself and coworkers have been successful with the 'keyup' event for textareas and text fields. Checkboxes, radio buttons, and selects we have used 'change'. It would be prudent to investigate the subtle nuisances and differences between 'keyup', 'keydown', and 'keypress' as they are all very similar but all have "gotchas". We also made sure to recheck the form upon submission, and then check again on the server-side, which I have no doubt you are doing.

You may also want to take a look at the 'paste' event. If you are restricting for example a phone number field and only accepting numbers, the user would still be able to copy and paste invalid input into the text field. And the pasted text is not standard across browsers, meaning you will have to do some checking to get the proper pasted value (even with jQuery). We have used this in a recent project:

function vendorDebtPaste(event) {
    var currentValue = $(this).val();
    var pastedValue;

if(window.clipboardData) { // IE
    pastedValue = window.clipboardData.getData('Text');
}
else { // Real browsers
    pastedValue = event.originalEvent.clipboardData.getData('text');
}

// do what you need to do
}

Lastly, if you don't have to support old browsers (<= IE 9) you can look into HTML5 form validation. There are also two pseudo classes in CSS you can use to style valid and invalid elements, :valid and :invalid.

Hope that helps!

[sneakyimp]

Thanks for your response.

Bonesnap;11053769 wrote:

I think part of it depends how "quickly" you want to validate. What I mean by that is if you want to validate as the user is using the form, or upon submission. Traditionally I do it on submission because it really simplifies the whole thing and keeps code to a minimum.

Bonesnap;11053769 wrote:

For validating as the user types, myself and coworkers have been successful with the 'keyup' event for textareas and text fields. Checkboxes, radio buttons, and selects we have used 'change'. It would be prudent to investigate the subtle nuisances and differences between 'keyup', 'keydown', and 'keypress' as they are all very similar but all have "gotchas". We also made sure to recheck the form upon submission, and then check again on the server-side, which I have no doubt you are doing.

I've been instructed that validation should happen as the user types/clicks/whatever. I've been told one must also listen for paste and autocomplete operations to cover all the bases. I'm pretty concerned about multiple events firing when a change is made.

Bonesnap;11053769 wrote:

You may also want to take a look at the 'paste' event. If you are restricting for example a phone number field and only accepting numbers, the user would still be able to copy and paste invalid input into the text field. And the pasted text is not standard across browsers, meaning you will have to do some checking to get the proper pasted value (even with jQuery). We have used this in a recent project:

function vendorDebtPaste(event) {
    var currentValue = $(this).val();
    var pastedValue;

if(window.clipboardData) { // IE
    pastedValue = window.clipboardData.getData('Text');
}
else { // Real browsers
    pastedValue = event.originalEvent.clipboardData.getData('text');
}

// do what you need to do
}

I know that jQuery can bind to a paste event:

$("#textareaid").bind("paste", function(e){
    // access the clipboard using the api
    var pastedData = e.originalEvent.clipboardData.getData('text');
    alert(pastedData);
} );

I'm not really following what you are saying, though. Wouldn't you want to examine the val() of the input element to find out what value is in there? Or does the paste event fire before the pasted data is assigned to the input?

Bonesnap;11053769 wrote:

Lastly, if you don't have to support old browsers (<= IE 9) you can look into HTML5 form validation. There are also two pseudo classes in CSS you can use to style valid and invalid elements, :valid and :invalid.

Hope that helps!

This certainly does help. Thank you.

[Weedpacket]

In the case of JavaScript (thanks to the notorious semicolon insertion behaviour), having the brace at the end of the current line vs. starting the next line can make a semantic difference to the program:

return
{
    foo: 'bar'
};

doesn't do what you probably expect it to do.

[Bonesnap]

sneakyimp;11053791 wrote:

I'm pretty concerned about multiple events firing when a change is made.

Is there a particular reason you are concerned about this? I don't believe more than one event fires for a single action. For example the 'paste' event will not fire the 'change' event.

sneakyimp;11053791 wrote:

I'm not really following what you are saying, though. Wouldn't you want to examine the val() of the input element to find out what value is in there? Or does the paste event fire before the pasted data is assigned to the input?

Yes, it fires before. So you can examine the pasted data, do any manipulations required, and then do with it what you want, usually just appending to the current value of the input field.

Oh, and while we are talking about IE. Since IE 10 the browser likes to add these little Xs in some of its text fields. If you are looking for the event that fires when they are clicked, it's the 'input' event.