The Thankless Complexity of Custom Form Validations

One of the least exhilarating but common development tasks are building forms, and form validations. While important, they're often over-designed and easy to over-engineer as a result. I believe we've gone too far with trying to accomodate all kinds of form validation while building reusable input fields –– especially for component libraries and design systems. The Browser Already Handles It Default HTML5 on-submit validation in Chrome. This is what happens when the submit event is called on a form and the incorrect data or required fields are not filled as a result of the HTML constraint validation API calling checkValidity() on ElementInternals or form.validate() methods. The most basic validation happens on submit, when the user hits a "submit" button associated with a form element. It's not styled nicely. It doesn't look or feel consistent look across browsers, but IT JUST WORKS. Form input elements have built-in validation attributes for min, max,step, minlength, maxlength values, and regex matching on the pattern attribute for things like phone number format masking. If you stick to validating on submit, could very well validate a form without using Javascript! 1 The drawback: errors that show up from failed submission attempts won't disappear til the user retries submitting the form. All the ways to validate Each type requires invoking validation on the form field at different moments of the user journey. Validation as the user interacts with a field (oninput, onchange, onkeypress). Also called "live validation". Slack's implementation of live validation on a password field with a strength meter under the field provides instant feedback on whether the user's password fulfills password rules. Validation that runs when the user pauses, or has finished typing in a field (onkeyup with debounce) is less common besides finding them on username and password fields. I don't think it's necessary to including such behaviour on regular input fields in component libraries. Validation that runs on submission (onsubmit) - and should prevent any erroneous data being posted if there are errors in any form field. Validation that shows on fields after form submission due to responses from the server One would expect that post-submission, server-side errors are reflected on the form, under corresponding fields that had incorrect content. Validation that runs right after the user has interacted with the field (onblur) - otherwise called "late validation" Unpopular opinion: I recommend sticking to this when there is a need to build ultra-fast. You will dig your own grave otherwise. Agreeing to implement live validation, if not scoped carefully, will result in hellfire from all directions since: validation can run prematurely and aggressively, especially on fields that are required but incomplete. you'll be playing whackamole to remove validation errors whenever they're corrected, which means detecting change oninput or onkeypress and removing the error message when the field is valid again, particularly on fields that are dependent on each other. you end up tempted to add more feedback mechanisms like toasts to prove the form submitted Treacherous Variants Let's look at some well-intentioned UX patterns that explode the combinatories of visual and accessiblity testing since form layouts are so varied. Andrew Coyle, "Forms need validation", Medium, Dec 16. 2016 The option to show validation messages above, below, or adjacent to a form field Showing validation errors inside a tooltip or popover Showing multiple validation messages above, below, adjacent to any form field

Apr 3, 2025 - 03:21

The Thankless Complexity of Custom Form Validations

One of the least exhilarating but common development tasks are building forms, and form validations. While important, they're often over-designed and easy to over-engineer as a result.

I believe we've gone too far with trying to accomodate all kinds of form validation while building reusable input fields –– especially for component libraries and design systems.

The Browser Already Handles It

Default HTML5 on-submit validation in Chrome. This is what happens when the submit event is called on a form and the incorrect data or required fields are not filled as a result of the HTML constraint validation API calling checkValidity() on ElementInternals or form.validate() methods.

The most basic validation happens on submit, when the user hits a "submit" button associated with a form element.

It's not styled nicely. It doesn't look or feel consistent look across browsers, but IT JUST WORKS.

Form input elements have built-in validation attributes for min, max,step, minlength, maxlength values, and regex matching on the pattern attribute for things like phone number format masking.

If you stick to validating on submit, could very well validate a form without using Javascript! ¹

The drawback: errors that show up from failed submission attempts won't disappear til the user retries submitting the form.

All the ways to validate

Each type requires invoking validation on the form field at different moments of the user journey.

Validation as the user interacts with a field (oninput, onchange, onkeypress). Also called "live validation".

Slack's implementation of live validation on a password field with a strength meter under the field provides instant feedback on whether the user's password fulfills password rules.

Validation that runs when the user pauses, or has finished typing in a field (onkeyup with debounce) is less common besides finding them on username and password fields. I don't think it's necessary to including such behaviour on regular input fields in component libraries.

Validation that runs on submission (onsubmit) - and should prevent any erroneous data being posted if there are errors in any form field.
Validation that shows on fields after form submission due to responses from the server
One would expect that post-submission, server-side errors are reflected on the form, under corresponding fields that had incorrect content.
Validation that runs right after the user has interacted with the field (onblur) - otherwise called "late validation"
Unpopular opinion: I recommend sticking to this when there is a need to build ultra-fast. You will dig your own grave otherwise.

Agreeing to implement live validation, if not scoped carefully, will result in hellfire from all directions since:

validation can run prematurely and aggressively, especially on fields that are required but incomplete.
you'll be playing whackamole to remove validation errors whenever they're corrected, which means detecting change oninput or onkeypress and removing the error message when the field is valid again, particularly on fields that are dependent on each other.
you end up tempted to add more feedback mechanisms like toasts to prove the form submitted

Treacherous Variants

Let's look at some well-intentioned UX patterns that explode the combinatories of visual and accessiblity testing since form layouts are so varied.

Andrew Coyle, "Forms need validation", Medium, Dec 16. 2016

The option to show validation messages above, below, or adjacent to a form field
Showing validation errors inside a tooltip or popover
Showing multiple validation messages above, below, adjacent to any form field