Hacker News Reader

Comment by Macha | Hacker News Reader

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.

View on HN

There is the :user-invalid pseudo-class that lets you avoid this to some extent, but it has some inflexibility that may mean it isn't enough, depending on your use case.

https://developer.mozilla.org/en-US/docs/Web/CSS/:user-inval...

There ought to just be a property named something like `defer-validation` that does the right thing. But I'm sure I'm not the first person to suggest it, there's presumably some logistical or technical difficulty.

If I'm making a wish list I'd also like to point a property at a handler function that accepted a `string` and returned a `string | null` (or at least a `nonempty string | empty string`) rather than using an onchange handler, but it is what it is.

This is one of the main reasons people started using JavaScript, to show errors only after a form has been “touched” or right before it is submitted.

A bit perplexed by your comment. That wasn't a main reason people started using javascript.

I even remember when people started evangelizing client-side validation in the mid-2000s. Javascript was already a normal tool used in web apps by then, and most web developers would regularly be adding javascript to their apps.

Back then it was a bit of a pita as you had all sorts of gotchas with javascript memory leaks by registering change events on controls. I can't even remember the term now, but you could basically have a circular reference between a closure and a control and so it wouldn't cleanup properly.

Also, modern developers probably can't even begin to imagine how slow javascript was on IE6. A loop of a few 100 iterations could bring it to an unresponsive halt.

probably they mean why people started using JS in form validation, and not JS altogether, although agree that isn't the reason either.

Correct, I meant that client-side validation driven by JS became popular because of UX issues when using pure HTML. There have always been plenty of other reasons to use JS with forms besides validation. But it’s notable because forms and form validation are such common building blocks that if people feel the need to use JS there, it kind of infects everything else around it. IMO, being able to build high quality form experiences without JS is critical to reducing bloat on the web.

JS form validation quite significantly predates HTML form validation. The alternative was server side form validation, for the longest time. HTML form validation was meant to standardise and reduce the need for JS validation, but for UX reasons it hasn't really managed that. And that you'll need JS anyway if you're doing validation specific to your business logic that doesn't fit into the set of rules HTML validation has.

I've never understood why this was chosen as the default experience. Most users don't enjoy having every form element yelling at them for actions they haven't even had a chance to take! You can script around this, but at that point the feature isn't doing much. I'd argue this is the biggest reason you don't see more widespread adoption.

Perhaps the same reasoning that IDEs show syntax errors before you save the file? (No, I don't like that feature either.)

Reply on news.ycombinator.com