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
Your second point more relates to this.
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
select elements and shows error messages in the form. The thing jQuery Validate doesn't do is have custom date pickers, colour swatches etc.
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.
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).
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.