Live data from Hacker News

HTML Form Validation is underused

expressionstatement.com

251–260 of 343 posts

Re: HTML Form Validation is underused

#251

It's a bit disappointing that articles talking about HTML use JSX/React syntax instead of actual HTML (even more so not actually saying it). Example from the article:

It's exacerbated by the fact that the API they propose to make custom validation more ergonomic works for React, but would be much worse for plain Javascript and HTML.

The API I'm proposing would indeed bring much more benefit when used in a declarative way. That's the point I'm specifically trying to convey in the article.

I don't think I understand how it would be "worse" for plain JS and HTML though. Would love to hear your thoughts.

Actually, there is one possible concern. When HTML is returned by the server includes inputs with set "custom-validity" attributes and this HTML gets open by a browser with no javascript enabled, this would make the input "stuck" in an invalid state. This is an important edge case to consider but I do believe there is a resolution that would satisfy everyone

Re: HTML Form Validation is underused

#254

i'm not seeing the custom validation messages in these examples at all in Chrome. Others are?

That's weird! Have you tried submitting the forms in the examples? The custom messages are supposed to be shown in the native browser validation tooltips. The support for those is quite good! Even on mobile browsers

Re: HTML Form Validation is underused

#255
post #85

Here's a simple example that doesn't use React: https://developer.mozilla.org/en-US/docs/Web/API/HTMLObjectE...

I was thinking that it's so weird to talk about using standard HTML validation and then everything is shown with React? If we want to teach people how standard works, we can't assume React as the default.

Re: HTML Form Validation is underused

#256

> Using other input attributes that create constraints, such as "pattern" or "maxlength" No. Don't use the maxlength attribute. https://adamsilver.io/blog/dont-use-the-maxlength-attribute-...

That's great advice!

I also dislike the "character rejection" mechanisms, even though many people love it and products often ask to implement it.

To add to the possible solutions mentioned in your article, I'd add the "pattern" attribute. You can do something like this:

This will allow input of any length, but show a warning then the value is longer than six characters.

Re: HTML Form Validation is underused

#257

After reading all this, I think I'd still choose to do it away from the browser built in capabilities. I'd rather have full control over the process and the design than rely on the limited capabilities of browsers. 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.

I totally understand this. Having DOM elements as an entry to some API isn't the best thing.

But firstly, I would consider what you're missing when you abandon native validation

* On submit, the first field that needs attention gets focused automatically

* Error messages for semantic attributes are localized automatically by the browser

* The native message tooltip are actually nice and their placement is handled by the browser. They aren't the best fit for any design system, but for many products they are way nicer than custom implementations.

* Possible styling using CSS pseudo-classes such an ":invalid" or ":user-invalid"

In the end, I do think that the developers would benefit from a more explicitly exposed API for this. Just like we got the "new URL()" constructor, but earlier we had to create an anchor node, fill in its "href" attribute and then read the anchor properties to get to the parts of the parsed URL.

Re: HTML Form Validation is underused

#258
post #15

Earlier quoted context omitted.

Couldn't disagree more. Browser features can be much better at handling edge cases: disability, localisation, unusual devices, different input methods, weird screen sizes, etc... rather than hoping every developer does it right, building that in is more efficient and consistent. The common cases should be handled really well by browsers.

I couldn't disagree more; it might be good for disability but for localization, unusual devices, different input methods, weird screen sizes I have never seen that well executed by browsers. I almost always prefer a more full-featured alternative from a standard framework than whatever is lowest-common-denominator feature in a browser -- which also, depending on the browser, may or may not work the same or may or may…

> This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be.

In a way, yes. I do think there's a lot to improve from the browsers' side. I guess what I'm trying to say is that the "half baked" solution is also not quite as bad as "no solution" and 1) it can be improved, 2) it really can be used today if you know "how to cook it right"

Re: HTML Form Validation is underused

#259
post #243

Earlier quoted context omitted.

That's exactly the case where the "customValidity" attribute shines! I have nothing against regex and the "pattern" attribute is the way to go for many cases, but having this is an alternative is also very nice: const valid = value.length => 4 && isAlphanumeric(value); return ( )

AFAIK customValidity is not an attribute and you can only use an imperative setCustomValidity API which is terrible cumbersome to use in a declarative framework like React.

Yeah this is exactly what I'm writing about in the article :)

Re: HTML Form Validation is underused

#260

i'm not seeing the custom validation messages in these examples at all in Chrome. Others are?

That's weird! Have you tried submitting the forms in the examples? The custom messages are supposed to be shown in the native browser validation tooltips. The support for those is quite good! Even on mobile browsers

Yup. If it's just me, I guess it's some plugin I have installed or something.
Post reply on HN