Live data from Hacker News

HTML Form Validation is underused

expressionstatement.com

241–250 of 343 posts

Re: HTML Form Validation is underused

#241
post #42

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

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 ( )

Re: HTML Form Validation is underused

#242
post #42

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

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 ( )

Yeah well I promise it does read nicely when there's formatting which HN comments do not allow :)

Re: HTML Form Validation is underused

#243
post #42

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

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.

Re: HTML Form Validation is underused

#244
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.

EDIT: which I agree with.

Native HTML validation has many flaws and visual customization is not my biggest concern to be honest (but it's the nail in the coffin).

E.g.:

- It's impossible to show multiple errors at once per field unless you concat strings ("You need a number. You need a symbol. Must be >10 chars.")

This is both bad UX and bad for accessibility (you cannot navigate concatenated strings on the accessibility tree). And this isn't even implementation dependent, it's the spec! You need multiple errors at once because playing whack-a-validation-error is not fun for users.

- It's browser-dependent which is bad because you can'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's a popup (2) that shows modally (3) and can't show all form errors at once).

Not using popups for important information is accessibility 101, but browsers cannot afford to do anything else without interfering with the actual document.

- You still need custom validation for form-wide errors (like errors that don't belong to a particular field, "Fields A and B are incompatible") so you might as well have a consistent validation story.

- It requires you to have hidden inputs to be consistent (-ish) if you have some custom input that doesn'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.

- The custom validity API is imperative and cumbersome to use. Not using custom validity is almost never an option unless you want terrible messages ("This field is invalid")

And many more.

HTML form validation is terrible.

Re: HTML Form Validation is underused

#245

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:

Sorry to disappoint, I did hesitate over this. But JSX is honestly very nice to read and also I didn't want to leave the impression that opting in to native form validation somehow forces you to not use javascript. And combination of javascript + html is, again, very nicely expressed with JSX.

The concepts are obviously easily translated to other component frameworks, but they also do apply to pure HTML and vanilla javascript.

The problem I am highlighting in the article is the absence of a declarative nature to the Custom Validity API, so I think it makes sense to use a declarative component approach in code examples

Re: HTML Form Validation is underused

#246
post #244

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. EDIT: which I agree with. Native HTML validation has many flaws and visual customization is not my biggest concern to be honest (but it's the nail in the coffin). E.g.: - It's impossible to show multiple errors at once per field unless you concat str…

What was the auditors' reasoning for that?

Re: HTML Form Validation is underused

#247

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:

I thought the same thing. I was once discussing a third-party integration with a React developer. The integration required that our app POST a couple of fields to the third-party's site. I found that the developer was struggling with the integration and they were asking me questions about it when I said something to them along the lines of "It's just an HTML form, with a couple of hidden inputs that when submitted ma…

It's definitely true that many developers would benefit a lot from learning more about the basic HTML and the web platform. But I refuse to support the notion that this is somehow React's fault.

In my personal experience, react allowed me to rely more on the native web platform APIs, not less, than other frameworks (at the time that I switched to react)

Re: HTML Form Validation is underused

#248
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.

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.

Re: HTML Form Validation is underused

#249
post #98

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:

The confusion in the article is so complete that I'm left wondering whether or not the author is aware that what they are writing is not, in fact, HTML.

Yeah, I am aware! Thank you for the concern :) I did address this in an adjacent comment, but I'll say again that I did contemplate over using JSX or not. Also yes, it may have been a good idea to add a disclaimer for the fact that the code I'm showing is JSX, but honestly there are so many other disclaimers I had in mind, all of them together would make the article twice as long and much more boring

Re: HTML Form Validation is underused

#250
post #244

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. EDIT: which I agree with. Native HTML validation has many flaws and visual customization is not my biggest concern to be honest (but it's the nail in the coffin). E.g.: - It's impossible to show multiple errors at once per field unless you concat str…

What was the auditors' reasoning for that?

That the browser implementations are generally terrible and wouldn't pass accessibility audits, so all browsers would have to change and then some time to pass for the fixed versions to be widespread.

We didn't discuss browser-specific issues in detail, but I edited some points in my original message that highlight some of the issues that I suspect make it a no-go for accessibility.

Post reply on HN