HTML Form Validation is underused

Last time I checked, web-browsers today <i>still</i> do not allow you to style the appearance of built-in HTML validation messages [1]; this wouldn&#x27;t be so bad if Chrome (and Firefox) still conformed to their OS platform UI guidelines (i.e. so it looks system-generated, like how `title=&quot;&quot;` tooltips used to be), instead Chrome uses this ugly yellow&#x2F;orange icon color with black-text on a white background on a bubble with a fixed corner border radius - it clashes horribly with my current project&#x27;s aesthetics.<p>[1] <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;5328883&#x2F;how-do-i-style-the-html-form-validation-error-messages-with-css" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;5328883&#x2F;how-do-i-style-t...</a><p>Annoyingly, Chrome <i>used to</i> allow styling of validation-messages using vendor-prefixed pseudoelement selectors, but they removed that functionality and never brought it back; I&#x27;ll chuck this on the same pile as other arbitrary annoyances like &quot;can we have a native HTML combo-box please&quot; and &quot;why is &lt;select multiple&gt; still a horribly unusable ctrl+click box instead of a checkbox-list?&quot;.

The biggest, easiest to implement underutilization is:<p>&quot;Using specific type attribute values, such as &quot;email&quot;, &quot;number&quot;, or &quot;url&quot;&quot;<p>These can significantly improve user experience on mobile by triggering the optimal keyboard.

My product just failed an accessibility audit because we are using native HTML form validation and the official recommendation was to implement our own validation layer.<p>EDIT: which I agree with.<p>Native HTML validation has many flaws and visual customization is not my biggest concern to be honest (but it&#x27;s the nail in the coffin).<p>E.g.:<p>- It&#x27;s impossible to show multiple errors at once per field unless you concat strings (&quot;You need a number. You need a symbol. Must be &gt;10 chars.&quot;)<p>This is both bad UX and bad for accessibility (you cannot navigate concatenated strings on the accessibility tree). And this isn&#x27;t even implementation dependent, it&#x27;s the spec! You need multiple errors at once because playing whack-a-validation-error is not fun for users.<p>- It&#x27;s browser-dependent which is bad because you can&#x27;t control it and because the implementation is generally terrible (e.g. in Chrome it shows a popup on focus, which is not very accessible by itself because (1) it&#x27;s a popup (2) that shows modally (3) and can&#x27;t show all form errors at once).<p>Not using popups for important information is accessibility 101, but browsers cannot afford to do anything else without interfering with the actual document.<p>- You still need custom validation for form-wide errors (like errors that don&#x27;t belong to a particular field, &quot;Fields A and B are incompatible&quot;) so you might as well have a consistent validation story.<p>- It requires you to have hidden inputs to be consistent (-ish) if you have some custom input that doesn&#x27;t fit any of the native input types -- this breaks accessibility too and fixing it is as hard as having your own accessibility-friendly validation story.<p>- The custom validity API is imperative and cumbersome to use. Not using custom validity is almost never an option unless you want terrible messages (&quot;This field is invalid&quot;)<p>And many more.<p>HTML form validation is terrible.

In an all honest reply, is that the people that writes these specifications, live disconnected from the reality, they don&#x27;t use the stuff they specify. That stuff works for very simple things, but then when your forms evolve you realise you will be better off just writing the whole thing yourself.

If you have a checkbox with a label, please a &quot;for&quot; attribute to the label so I can disable&#x2F;enable the checkbox by clicking the label. This is one of my biggest pet peeves, maybe its just me.

Here&#x27;s a simple example that doesn&#x27;t use React:<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;HTMLObjectElement&#x2F;setCustomValidity" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;HTMLObjectE...</a>

Html form validation is great. There&#x27;s just one gigantic catch:<p>It doesn&#x27;t work in Firefox for Android.<p><a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1510450" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1510450</a>

You gotta be careful about going overboard with it.<p>Recently I was trying to get a refund on Groupon because the company I&#x27;d bought a Groupon for was under new management that refused to honor my groupon.<p>The form had a stipulation &quot;minimum of 15 words&quot;. Try as I might, I could not get the form to pass validate until I inspected the HTML.<p><pre><code> &lt;input pattern=&quot;^(\b\w+\b\s*){15,}$&quot; required&gt; \w - word characters \b - word boundaries \s - white </code></pre> Literally zero allowance for any sort of punctuation.

There’s a reason it’s heavily underused. So many frameworks and libraries provide robust, style-able validation capabilities, some with very sophisticated and extendable functionality. Don’t torture yourself if you don’t have to.

One of the things I dislike about HTML form validation is it starts running from page load. So if e.g. you tie error state formatting to it, the form loads up with a bunch of errors which may be intimidating to the user.

My personal bête noire is sites that misuse type=password for 2FA inputs, since that confuses password managers and browsers both.

Because it sucks.<p>It does not translate with the application but with browsers settings, it doesn’t style or fit any design. It looks differently on different browsers and it is really hard to explain to stakeholders “this is from browser I don’t have control over it”.

The real problem with client-side validation is you can&#x27;t trust it.<p>You need to revalidate on the server, no matter what.

simply adding required is all you need.Not required=true The omission is equal to required=false. No one really write required=true, they just add the attribute `required` only by its self. This is one of the odd quarks about html attrs<p>Same is true for things like disabled ect <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Glossary&#x2F;Boolean&#x2F;HTML" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Glossary&#x2F;Boolean&#x2F;HT...</a><p>&gt; The strings &quot;true&quot; and &quot;false&quot; are invalid values. To set the attribute to false, the attribute should be omitted altogether. Though modern browsers treat any string value as true, you should not rely on that behavior.<p>in other words required=false may still end up making the field required. FYI.

&gt;Imagine a username input that should be valid only if the username is not taken<p>Maybe that is user friendly but for sure I don&#x27;t like to see the backend bombarded with API calls each time an user types a letter.

Ya&#x27;ll may want to checkout Valibot¹ or Zod² in conjunction with something like React Hook Forms³ or the more agnostic Tanstack Forms⁴. Really sweet form validation that&#x27;s concise but as precise as you want it to be.<p>The problem with vanilla form validations are (1) they&#x27;re so basic that it&#x27;s table stakes for any library or framework in this space, even ChatGPT can do it well, (2) there&#x27;s an enormous amount of other validation scenarios they don&#x27;t cover, and (3) unless your validation is simple and doesn&#x27;t require a validation library, now your logic is split between two places.<p>[1]: <a href="https:&#x2F;&#x2F;valibot.dev&#x2F;guides&#x2F;comparison&#x2F;" rel="nofollow">https:&#x2F;&#x2F;valibot.dev&#x2F;guides&#x2F;comparison&#x2F;</a><p>[2]: <a href="https:&#x2F;&#x2F;zod.dev&#x2F;?id=basic-usage" rel="nofollow">https:&#x2F;&#x2F;zod.dev&#x2F;?id=basic-usage</a><p>[3]: <a href="https:&#x2F;&#x2F;www.react-hook-form.com&#x2F;get-started&#x2F;#SchemaValidation" rel="nofollow">https:&#x2F;&#x2F;www.react-hook-form.com&#x2F;get-started&#x2F;#SchemaValidatio...</a><p>[4]: <a href="https:&#x2F;&#x2F;tanstack.com&#x2F;form&#x2F;latest&#x2F;docs&#x2F;framework&#x2F;react&#x2F;quick-start" rel="nofollow">https:&#x2F;&#x2F;tanstack.com&#x2F;form&#x2F;latest&#x2F;docs&#x2F;framework&#x2F;react&#x2F;quick-...</a>

The best native HTML validation is server-side validation.<p>The only downside: the user has to wait 300ms.

I share the wish that there was more effort in the browser space to improve the built-in controls but I would also recommend that people thinking they can easily do better try some real usability and especially accessibility testing. One very nice trait of the standard APIs are that they’re very lightweight and people who build assistive tools like screen readers and Braille displays know about and support them.<p>It is so easy for developers to think they have something better after a simple NPM install, until they test it on a slow (i.e. median) phone or watch a blind person try to use their application and then spend weeks trying to improve things. Given how common web forms are it’d be really nice if we had an Interop-style competition focused on making the out of the box experience better for normal people both for the controls integrated in browsers and the myriad of JavaScript widgets.

It&#x27;s also easily misused. Take the regular expression validator for passwords on the California DMV website, for example. The website states &quot;Must include at least 4 alpha characters&quot;. But the validation pattern<p><pre><code> ^(?=(.*[a-zA-Z]){4,})(?=.*[0-9!#$%]).+$ </code></pre> requires that these characters appear <i>consecutively</i>.

Bizarrely, url validation requires the <a href="https:&#x2F;&#x2F;" rel="nofollow">https:&#x2F;&#x2F;</a> prefix

One gets the feeling HTML in general is underused, since everything has been done in JavaScript for... How long now, at least over a decade?<p>It&#x27;s gone so far that some peole claim React (and probably other frameworks too) is &quot;a language&quot;; they apparently don&#x27;t even know it&#x27;s just a JavaScript library.

I do get the point of using form validation clientside to ensure a better ui.<p>But dont remenber to also verify serverside. Anything clientside can have been fumbeled with. (Also kinda anoying to have to duplicate this tho)

It&#x27;s a bit disappointing that articles talking about HTML use JSX&#x2F;React syntax instead of actual HTML (even more so not actually saying it). Example from the article:<p><pre><code> &lt;input required={true} &#x2F;&gt;</code></pre>

once you grasp the ergonomics of <i>setCustomValidity()</i> you can go crazy e.g. pass it a multitude of validation rules per input field.<p>unfortunately you’re sort of back to square one if you want to implement warnings (ie suboptimal inputs but still workable).<p>Edit: While grasping the ergonomics produces euphoria like solving a complex puzzle it’s also a hint at the pain un-initiated colleagues will feel when tasked with maintaining the code.

After reading all this, I think I&#x27;d still choose to do it away from the browser built in capabilities. I&#x27;d rather have full control over the process and the design than rely on the limited capabilities of browsers.<p>The browser is programmable; at this point they should stop getting clever about adding built-in functionality and instead just expose better ways to use the browser as a dumb UI toolkit.

No it isn’t. It fucking sucks. Most everyone who learns HTML comes across the validation attributes, the god awful built in date pickers and other shit, and they throw it out in favour of custom built better UX implementations. Maybe in the past we would have been clueless because, well, they didn’t exist, but today they do. And they’re junk.<p>Call spade a spade. Don’t call it heavily underused.

The last example is bad. You shouldn&#x27;t scream at your users before they even had a chance to enter the required information so the second password field should not be marked red until the user either is done entering text there (onblur) or tries to submit the form.

this is just react though. it&#x27;s not HTML validation.

That&#x27;s nice, I&#x27;ll use that next time. Although it always feels kind of bad to write client side validation code because you&#x27;re going to have to do the same checks on the server side anyway.

&gt; Using other input attributes that create constraints, such as &quot;pattern&quot; or &quot;maxlength&quot;<p>No. Don&#x27;t use the maxlength attribute.<p><a href="https:&#x2F;&#x2F;adamsilver.io&#x2F;blog&#x2F;dont-use-the-maxlength-attribute-to-stop-users-from-exceeding-the-limit&#x2F;" rel="nofollow">https:&#x2F;&#x2F;adamsilver.io&#x2F;blog&#x2F;dont-use-the-maxlength-attribute-...</a>

Built-in validation is pretty much the only reason I use forms.<p>Capturing input with frameworks is much simpler than pulling the values out of an event object, so I&#x27;d be okay with just using input and button elements.<p>Yet, that doesn&#x27;t trigger the validation, so I end up wrapping it with a form element and using a submit button.

Do we finally have a standard solution for input masks ? 25 years ago I was struggling with this while my fellow desktop app devs had good input masks in their widgets, with easy to use pattern syntax. That would be embarrassing if not.

Guilty. Recently, when I was involved in a project that required a lot of attention to forms, I ended up overlooking the importance of basic simplicity. I regret it a bit. Thanks for sharing your perspective.

Are we seriously talking of HTML by using React examples? The article doesn&#x27;t even explicitly aknowledge the fact that it is written within the context of react.

A lot of HTML features are underused with everything being done in JS libraries now rather than using built in functions.

In React I just use Formik and Yup to make forms painless. I&#x27;ve yet to discover a better way.

i&#x27;m not seeing the custom validation messages in these examples at all in Chrome. Others are?

everything html offers more exotic than playing text leaves a bad taste in the month thanks to bad implementations.<p>yeah i can mark a field as numeric... but then when a phone renders the number only input all popular keyboards will also leave out every single clipboard buttons and helpers. url where you can also search if you type a phrase? too bad you just lost all typing correcting and prediction. it&#x27;s lame and hopeless.