FormValidation

Page history last edited by Todd Parker 11 mos ago

 

type: utility

realease: 0.0

priority: very low

status: in planning

documentation: 

demo:

 


 

1 - Description:

 

Terms:

  • method: A validation method abstracts a certain behaviour, like an email method that validates email addresses
  • rule: A field-method pair, like "username is required"

 

The validation plugin should allow validation rules to be bound to any form fields.  The most common use case is to validate a form by validating all of its elements and preventing the form from submitting if it is invalid.  However, we need to consider the use cases of validating subsets of forms and fields that are defined outside of a form.

 

There will be a range of validation methods that can be applied, such as:

 

  • Boolean Values: Required Field
  • Comparison Values: Password Validation, Field != Other Fields, Field =< Other Field, Field >= Other Field, Field == Other Field
  • Type Values: Numeric Value, Date, Email, URL, Credit Card, Phone Number
  • Range Values: Min, Max, Between Values, both numeric and length
  • Dependencies: Apply or skip a rule depending on the result of a selector or callback

 

The plugin will provide the most useful methods, as well as a way for users to add their own custom methods, in addition to a repository where custom methods are gathered.

 

Displaying validation messages requires a lot of customization, as form layout and various requirements varies a lot. The reference plugins defaults to displaying messages next to each input, which is rather obtrusive.

A better default would be to display a general warning at the top of the form on an invalid submit, indicating something like "You've missed 6 fields, they have been highlighted below". Each required but empty field is then highlighted. On editing individual fields more specific messages are displayed in a tooltip next to the field, eg. when entering an invalid email address, the tooltip next to the field displays a message accordingly.

 

In any case, whenever a message is displayed, the form shouldn't shift, that is, messages inserted into the DOM should replace a placeholder. There should also be the option to fade in those messages, in order to make the experience even less obtrusive.

 

The design team needs to develop visual treatments for the validation messaging (icons, color coding) and work to integrate these into Themeroller. We'll need to create a few TR icons and add them to the sprite set at the very least.

 

The HTML5 spec for input elements:

http://www.w3.org/html/wg/html5/#the-input-element

 

Custom methods and attributes should use the naming conventions of HTML5 where feasible.

 

The Web Forms 2.0 spec, which defines the new input types and validation system for HTML 5.

 

Related jQuery Plugins:

 


 

2 - Visual Design:

 

 


 

3 - Functional Specifications/Requirements:

 

(Detailed descrition of how the script will be structured: defaults, options, architecture, extensibility, etc.)

 


 

4 - Markup & Style:

 

     4.1 Initial markup examples

 

     (Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )

 

     4.2 Recommended transformed HTML markup

 

     (The HTML markup structure and classes that will be used by the scripts in the enhanced version) 

 

     4.3 Accessibility recommendation

 

    (Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices) 

 

     4.4 CSS & Theme

 

    (Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.) 

 


 

5 - Latest version of plugin:

 

(Link to the latest version in the jQuery UI trunk here)

 


 

6 - Open issues being discussed

 

(Use this area to place things that we're hashing out like featuresand options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)

 


 

 

Comments (16)

profile picture

Scott González said

at 9:02 am on Nov 16, 2008

Handling the new input types that Web Forms 2 defines may be tricky, due to limitations on how browsers support custom type attributes. See the comments at the top of the web forms plugin (linked in section 8) and also see the comments in jQuery's implementation of $.attr().

profile picture

Jörn Zaefferer said

at 2:34 pm on Nov 18, 2008

I like the drafts for the password meter visuals. If somebody could extract the necessary graphics, I'd add them to the current validation-password-meter.

Same for the warning-icon, haven't yet seen that anywhere.

profile picture

Scott González said

at 2:17 pm on Nov 19, 2008

From Rich Caloggero:

How to discover errors in form submissions is a tricky issue for screen
reader users.

I think the best approach might be to:
1. do as Scott suggests and place a summary of the error(s) at the top of
the form or page (using an HTML heading or aria header role so screen reader
users can find it easily).
Might even be useful, especially in formw with many fields, to place a list
of pointers to the invalid fields just after the error message at the top of
the form.

I believe there is an aria-invalid state that should go on the field itself.
See the following blog entry for a bare-bones implementation which actually
works well for screen reader users right now:
http://www.marcozehe.de/2008/07/16/easy-aria-tip-3-aria-invalid-and-role-alert/

It uses a combination of aria-invalid and role:alert to give a message to
the user when the form element loses focus. The aria-invalid on the field
itself causes the screen reader to issue a message when theat field gains
focus.

profile picture

Andrew Powell said

at 8:48 am on Mar 11, 2009

Just wanted to chime in with something I found the other day. Currently we use a very basic inline validation/notification method. A small div is displayed on the page with the elements which need to be corrected, and corresponding messages. The visual design proposed looks great, and would be outstanding for an inline approach. However, for working with forms on existing applications, which cant nessesarily be redesigned to support inline validation messages, something like this (http://mootools.floor.ch/en/demos/formcheck/post-comment/) would be ideal.

While this certainly isnt everyone's cup of tea, it's ideal for an application im working on, and I'll be porting this to jQuery within the next week or two. I think this kind of an option, for the 'bubble notifications', would be a value-add feature for the validation plugin.

profile picture

Matt Smith said

at 11:04 am on Jul 8, 2009

I wanted to add my little effort as this is something that I really think is important especially if I am going to keep using UI for our CMS admin GUI framework.

http://www.800px.com/ui-input/

I have designed a basic html structure for an input element that can display and validate against a type. this is no where near as advanced as the example plugins but the html is sound and the CSS seems to work and be unobtrusive to the overall document formating.

I have included the proposed UI CSS framework classes for form inputs but have also used existing UI CSS classes to enable the fields to fit in in some way with the overall UI look and feel.

I would like to push this further to implement the webforms 2.0 validation API and see no reason why the example password strength meter cannot be included as well. I would value feedback on the effort so far and whether I am pushing in the right direction for this validation framework.

profile picture

Todd Parker said

at 12:07 pm on Jul 8, 2009

Hi Matt - This is looking really slick, nice work. I especially like how the validation message fades in and out in the last few examples. The examples where the validation messages obscures the imput might be a usability issue though. If you want to take a crack at the password strength element, that would be a nice addition. I thought there was a jQuery based version out ont eh web already but the links to it seem broken. It might be good to continue working on this script on your own since it's not a high priority for the team right now. Just keep everyone updated on your progress here by posting links and feel free to ask for input as you go.

The closer you code conforms to UI's conventions, the easier it will be to accept this for the official plugin process later so the fact that you're using the CSS framework is great. Try to dig around though the dev docs and through the existing UI plugins to get a sense of how we code.

profile picture

Matt Smith said

at 11:21 am on Jul 27, 2009

I've written my formvalidation utility so that it has a string validator which allows the adding of new rules and new messages. the widget of the same name attaches to input fields and fires events that can be added to.

usage would be;

$.ui.formvalidation.addValidator(name, method, message);

and;

var result = $.ui.formvalidation.validate('matt@800px.com', { 'email': true });
var result = $('<input name="email" value="" />').formvalidation({ required: true, 'type': 'email' }).formvalidation('validate');

The now seperate input widget adds event handlers and styling to the basic input element and allows you to set up formvalidation using the form validation utility like so;

$('<input name="email" value="" />').input({ validation: true, rules: { required: true, 'type': 'email' } });

I have a password strength validator that returns a percentage rating and checks against the 'min' option. I need to add the code to the input field so that it can utilize the results of this function.

The input widget could have placeholder code adding so you don't need labels but it does currently add the value of any associated label to the helper message.

I have begun the identification of forms as validation wrappers but not yet added form messaging. I have left other elements but plan on something similar so you don't need fields inside forms (for none post purposes).

There is also no code yet to check other input fields such as radio/checkboxes and select fields.

I only have basic tests set up so far, so they aren't particularly reliable yet. anyway I added them all her for you to check over;

http://www.800px.com/ui-input/

profile picture

Matt Smith said

at 8:58 am on Sep 17, 2009

I'd like comments on my ui.formvalidation scripts;

http://clients.800px.com/ui-formvalidation/

This includes;

function: $.formvalidation(value, rules);
widget: $('<input />').formvalidation(options);

you can also use the widget on a form;

http://clients.800px.com/ui-formvalidation/form.htm

As well as this I've created a ui.input widget which basically makes input styling a bit more ui friendly;

http://clients.800px.com/ui-formvalidation/ui.input.htm

All comments would be very appreciated.


profile picture

Todd Parker said

at 9:50 am on Sep 17, 2009

Hi Matt - Thanks for sharing this. From a design perspective, the first example looks really good. Nice use of the framework styles and the little password strength indicator is slick.

The ui.input widget demo seems to have some styling issues. If you choose a dark theme like ui-darkness, you end up with dark text on a dark background so it looks like the theme text color isn't inheriting properly. Is the text color hard-coded anywhere? If not, maybe the ThemeRoller CSS needs a tweak to work better on inputs. Personally, I'm not as into styling inputs so heavily so I actually prefer the first demo more where you just layer in error classes and don't try to style the default, hover and success states of the input. Some projects might really benefit from this so it's a nice option to have as long as you can control which theme elements you want in play - corners, states, feedback level, etc.

profile picture

Matt Smith said

at 12:15 am on Sep 18, 2009

thanks Todd I'll have a look at the input fields on the darker colors, I made sure I didn't set any colors and also made sure that I put the in planning form field CSS classes after the basic CSS state classes so that if you implement those they would work.

I'd really like to not use the ui.input but still include the icon in the basic formvalidation however, my CSS testing has so far proved to be flawed in some browsers because of the use of padding and width to ensure that the text doesn't run under the icon. Any ideas on that with out using the wrapper divs I use in ui.input would be great.

One thing I did notice with the progress bar is that when it gets near to 100% it suddenly lengthens not sure why but it's noticeable.

profile picture

Matt Smith said

at 2:10 am on Sep 18, 2009

Ignore the note about the progress bar I've just realised that it's the text length thats pushing it out

profile picture

Matt Smith said

at 12:10 pm on Sep 20, 2009

I've fixed the fot color issue I forgot to inherit on the input field

profile picture

sompylasar said

at 12:53 pm on Sep 18, 2009

Don't know if it is a widget logic or a client handler, but url validation is missing top-level domains: e.g. http://localhost/ which is a valid url.

And some glitch in string length test: "Demo 11 must be longer than -1 characters" where -1 must be 20.

profile picture

Jörn Zaefferer said

at 5:00 pm on Sep 18, 2009

If you accept that as a valid URL, people will complain thats its in almost every case NOT a valid URL...

profile picture

sompylasar said

at 3:01 pm on Sep 30, 2009

If this kind of check is in the core of the plugin, that might become a customizable option cause otherways a user would have to write his own _similar_ check.

One-level domains are useful where local testing could be applied but the validation is still required and cannot be removed entirely (e.g. a site based on a CMS is often built on a local machine and then uploaded into production environment - the CMS has this plugin as validating and eventually allows no local testing).

That is likely a rare usecase but is still a usecase.

profile picture

Matt Smith said

at 12:12 pm on Sep 20, 2009

thanks for pointig that out, -1 is the value of the maxlength attribute in some browsers by default chrome is somewhere in the 500k. It was stupid error where I was looking at the attribute not the widget rule value.

You don't have permission to comment on this page.