Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML Form Validation is underused

expressionstatement.com

Post reply on HN
Print view View original

41–50 of 343 posts

Re: HTML Form Validation is underused

#41

Post by maxbond »

Latty wrote: post #17
Macha wrote: post #9

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.

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.

Re: HTML Form Validation is underused

#42

Post by montag »

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.

Re: HTML Form Validation is underused

#43

Post by dotancohen »

wvenable wrote: post #35
JoshTriplett wrote: post #30

Earlier quoted context omitted.

Browser functionality is typically (handwaving on exact numbers here) better than the worst 80% of sites, on par with the next 10%, and not as good as the top 10%. If you're putting in the effort to build a site in the top 10%, sure, you might not want to be "held back" by the browser. But the vast majority of sites would do better by using what's built into the browser. And I would argue that the value the user rece…

I don't know, what browser functionality are we talking about? Even this form validation has to be implemented; I don't think I've ever even seen it in the wild. What percentage of websites are rolling their own functionality instead of using any one of the various library and framework that do this better? There is no way that every single browser is going to implement some high-level feature in a satisfactory and f…

  > There is no way that every single browser is going to implement some high-level feature in a satisfactory and future-proof. It's the wrong place to do it.
There are far more websites than web browsers, and the turnover at the typical web agency is very high. There is no way that every single web dev is going to implement form validation in an accessible, secure, and his-webdev-replacement-proof way across all browsers and devices.

Re: HTML Form Validation is underused

#44

Post by 354896547981565 »

DaiPlusPlus wrote: post #40

Last time I checked, web-browsers today still do not allow you to style the appearance of built-in HTML validation messages [1]; this wouldn'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=""` tooltips used to be), instead Chrome uses this ugly yellow/orange icon color with black-text on a white background on a bubble with a fi…

True. But you can hide the default message and replace it with your own. You'll still benefit from the form validation.

Re: HTML Form Validation is underused

#45

Post by ryncewynd »

nikeee wrote: post #31
pbreit wrote: post #11

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

I avoid the use of `type=number` and use `type=text inputmode=numeric` instead. It doesn't come with these arrow buttons which most users don't need anyway for entering numbers. Also the keyboard is better on iOS.

Thanks for the tip wasn't aware of that.

I rarely want those arrow buttons for numbers

Re: HTML Form Validation is underused

#48

Post by JoshTriplett »

wvenable wrote: post #35
JoshTriplett wrote: post #30

Earlier quoted context omitted.

Browser functionality is typically (handwaving on exact numbers here) better than the worst 80% of sites, on par with the next 10%, and not as good as the top 10%. If you're putting in the effort to build a site in the top 10%, sure, you might not want to be "held back" by the browser. But the vast majority of sites would do better by using what's built into the browser. And I would argue that the value the user rece…

I don't know, what browser functionality are we talking about? Even this form validation has to be implemented; I don't think I've ever even seen it in the wild. What percentage of websites are rolling their own functionality instead of using any one of the various library and framework that do this better? There is no way that every single browser is going to implement some high-level feature in a satisfactory and f…

Form validation, form elements, search... I've seen far too many sites try to reinvent a browser textarea or edit box, and fail at very basic things because they didn't handle anything they didn't personally think of. (Some common examples: some of the keyboard controls, or correct handling of scrolling when having enough text in the box to scroll, or the interaction between textarea scrolling and page scrolling...)

"satisfactory" is exactly what browsers tend to provide, with a side order of "no surprises". Designers reinvent browser functionality on a theory of "I don't want satisfactory, I want delightful and unique", and sometimes they succeed, but often they fail. As a user, I very rarely want "unique" when it comes to design.

You don't have to be held back by browsers, and you may well be able to do better, but many people who think they can do better end up doing worse.

Re: HTML Form Validation is underused

#49

Post by hn_throwaway_99 »

Jerrrrrrry wrote: post #37
yjftsjthsd-h wrote: post #25

Earlier quoted context omitted.

It's not a security feature, it's a UX feature.

True, but if there's a communication bug between UX and back-end teams, that can escalate into a false sense of security and then an exploit.

You were being downvoted here, but I think you make a great point.

The problem with having separate client-side and server-side validation logic is that you (generally) want the rules to be the same, but you end up needing to write them twice, usually in completely different technologies. I have seen many, many cases where the client-side validation and server-side validation got out of sync, and then just like you put it, obscure bugs or security exploits can arise from this.

In general, I think client-side validation should really only be used for the basics, often with respect to type (e.g. the email/URL examples given) and just basic "required" (non-empty) fields. Anything more complicated than that should be done solely server-side in my opinion - e.g. I wouldn't use setCustomValidity with a complex set of client-side rules. What I think is important, though, is to ensure that if the server validation fails that the error message that comes back is not just a single "Bad input!" message, but errors can be keyed by field to ensure you can display field-specific error messages and error highlighting.

Another option I considered back in the day when my backend was on NodeJS is to have the server return the text for a JavaScript validation function before the form itself is actually rendered. This, this function can be run client-side for immediate feedback when the user submits the form, but it's also the exact same logic that is run on the server when the form values are received.

Re: HTML Form Validation is underused

#50

Post by ryandrake »

wvenable wrote: post #35
JoshTriplett wrote: post #30

Earlier quoted context omitted.

Browser functionality is typically (handwaving on exact numbers here) better than the worst 80% of sites, on par with the next 10%, and not as good as the top 10%. If you're putting in the effort to build a site in the top 10%, sure, you might not want to be "held back" by the browser. But the vast majority of sites would do better by using what's built into the browser. And I would argue that the value the user rece…

I don't know, what browser functionality are we talking about? Even this form validation has to be implemented; I don't think I've ever even seen it in the wild. What percentage of websites are rolling their own functionality instead of using any one of the various library and framework that do this better? There is no way that every single browser is going to implement some high-level feature in a satisfactory and f…

As a user, I want common UI controls to look and behave the same way across all web sites. Ideally, across all applications on my OS, but that's also a lost cause. POLA[1]. I can accept if the developer wants to somehow extend an existing control to support something new, but it's so irritating when they just re-implement their own thing entirely because they think their ideas are better than the browser's. Multiply that mentality by every site out there, and you have the web as it is today: Everyone's site looks and feels inconsistent with every other site. And everyone ships a different 500 lines of code, each with different bugs, just to implement a drop-down box.

1: https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Post reply on HN