How best to implement HTML5 support for my validation library

Question

I have created an annotation-based validation library called regula. There seems to be some amount of interest around the framework and the next thing I'd like to do is to support HTML5 validation. Originally I figured that I would check to see if the browser supported the HTML5 validation that has been specified and to either emulate or delegate to built-in regula equivalents. This is trivial for things like required, but once you start getting into the date-validation, it gets tricky (date widgets, localization, etc.). So I have a few options in front of me:

• Full HTML5 Shim along with widgets (for date stuff etc.): I feel like this is overkill and essentially reinventing the wheel since this is already covered by things like modernizr.
• Use HTML5 validation if available (either native, or provided by shim; otherwise ignore): What this means is that if HTML5 validation is available (natively or through a shim) I will use it, otherwise I will ignore it.

I'm leaning towards the latter since currently if someone wants to use HTML5 validation, they will most probably require a shim since not all browsers support HTML5.

Which option do you think is better?

Answer 1

I am actually in the process of planning/building my own validation library and I had a similar dilemma. Basically, is it a validation library or a form/UI library? This is an important distinction.

Type of Library

Validation Library

Your second point more relates to this.

In my case I was looking more purely at validation before, looking at the intricacies of checking XYZ data is of the right format/type etc. I wanted to validate JavaScript objects, not forms (more on that a little later), so I am designing an architecture that allows me to map my validation requirements in the nicest possible way.

This is not to say a validation library doesn't interact with forms. Take jQuery Validate for example: it binds to the form element, can auto-add validation items based on attributes on the input or select elements and shows error messages in the form. The thing jQuery Validate doesn't do is have custom date pickers, colour swatches etc.

Form/UI Library

Your first point more relates to this.

Basically, you are attempting to use the native HTML5 controls where you can but otherwise providing some sort of custom interface for people to enter inputs on a form. While this definitely has uses, this isn't validation (not entirely anyway).

A form library may or may not have its own validation system though it can get about this another way. Take a custom date picker field for example, you might have a calendar and someone can just click the day they want but they have no other method via the UI to add arbitrary values. You've effectively limited it so you will "always" have a valid date.

While this method works, it isn't ideal. Having a well implemented validation system in place is good for future maintainers, they don't need to deal that the validation works because we are using ABC calendar instead of ZYX calendar.

HTML5 Validation

OK, the next question is do you really want to use/support HTML5 fields/validation when your library is being used?

This might come across strange but if you want consistency between the browsers, HTML5 fields might not be the way to go. This isn't so much because of the browser support for the various HTML5 fields but more so the little things like when they trigger validation (do you want it on blur or on submit?) and how the validation looks (you can partially get around this with CSS but it really depends on your design for how you want errors to look).

However HTML5 does have some really nice things like mobile devices changing the keyboard based on the input type, email validation (have you read RFC 5322? Getting a 100% correct method for email validation can be hard though that doesn't mean the browsers are 100% correct either), date pickers for date fields, colour swatch field and number field. These are all great but it really depends what you want to trade for that.

Putting that aside, it goes back to whether you want a form/UI library or a validation library.

How does this solve the my question?

In the end, your question is somewhat open-ended. You mentioned you want HTML5 support and you are already leaning to your second option. From what I can tell from your description, your second option is the fastest to implement and will save you hassles for your use case.

For those reasons, I would recommend you go that path.

However, I find "reinventing the wheel" isn't always as bad as what people think/say it is. Building a system from scratch, using the knowledge gained from working with other systems can have something amazing be built as a result. Obviously there is a lot of time involved in such project and many different things need to be accounted for though if you want consistency with how things look/act/work while having complete flexibility, this would be the way to go.

For my validation library, I have no intention to do any crazy date calculations myself. There is a great library called Moment.js which I intend to integrate with my validation system. I get the flexibility of my own validation system (fine grain control when validation fires, how the validation appears, its extendability) while getting the usefulness of work already built by others (and of course, crediting them).

Notes

I mentioned I wanted to validate JavaScript objects, not forms. This actually came from a big project I worked on where we started with plain jQuery Validate and eventually turned it into a hybrid monster that combined client-side and server-validation (by the power of ASP.Net, reading/writing attributes to inputs) while also working under very specific conditions (like multiple "forms" within a form tag - thanks ASP.Net WebForms!).

What I mentioned about HTML5 validation was from my own experiences over the years. With the browser support still evolving, this may change in the future.

Also, I am aware the question was asked 2 years ago. I do hope this answer is somewhat useful to whoever has a similar question in the future.