Live data from Hacker News

HTML Form Validation is underused

expressionstatement.com

161–170 of 343 posts

Re: HTML Form Validation is underused

#161

Earlier quoted context omitted.

I found this very extended with "date" input. It seems that every single frontend library has its own date widgets, and lots of them look awful in small screens. You have to add a JS and CSS just for that widget, some depending on jQuery. True, some of them are very configurable, but with the tiny cost of " " you have a widget that looks decent and native everywhere, probably cover your needs, and you can forget abou…

The native date input is terrible. Not the actual native control, which is usually okay, but the field itself. You can't even format the date! That's the number one reason I always use some datepicker library in combination with a regular text input.

IMO, you (the web developer) should not be formatting the date shown in the input widget. The input should be shown to the client following the system settings, so a US browser would show MMDDYYYY, while an European browser would show DDMMYYYY. And the field is correctly (IMO) normalizing all of them to ISO-8601 (YYYYMMDD) before sending it back.

And I have this opinion because I had to deal before with format configuration and normalization before saving to the database, when using a JS library. Now I just drop a "input type=date", and I know I'm going to get the ISO formatted date at the backend.

Re: HTML Form Validation is underused

#162

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…

[deleted]

Re: HTML Form Validation is underused

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

It’s amazing how many login forms are labeled “email” and then don’t have the correct type set.

I think that in some cases this could be because the inputs accept usernames as well as emails. But not in all cases, which is annoying!

Re: HTML Form Validation is underused

#164
post #23

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

> (Also kinda anoying to have to duplicate this tho) Security and convenience are like space and time, you can't move one without transformation of the other.

I think it's a trilemma between security, convenience, and architectural sophistication (NB: I'm deliberately not saying complexity, because the code doesn't necessarily get more complex). It is usually physically possible to find a solution with equal security for a given level of convenience, but it will require an investment of creativity and possibly refactoring to realize. Both of those things are very expensive.

To take an extreme example, you could ensure that validation happens identically on both the back and front end by writing your own framework with that property. You could create a framework with no more security bugs than the next best alternative and while providing great UX. But writing a framework and shaking out the bugs is a huge lift.

So in practice you can't go all the way out on the third axis and it is approximately a dilemma. But if you're on the lookout for exceptions you may find an opportunity to cheat/curve bend (eg as suggested by other commenters, when using JS for the front and backend, you can use data modeling libraries like Zod to get most of the benefit for a fraction of the price of writing a framework).

Re: HTML Form Validation is underused

#165
post #123

Earlier quoted context omitted.

And password managers will not fill in the credentials correctly.

Get a better password manager? I use Bitwarden and it has never failed to fill out the login forms for me.

Bitwarden has failed me on some sites.

Re: HTML Form Validation is underused

#166

Earlier quoted context omitted.

Nah. Users are too stupid to fix their own inputs in many cases. Seen inputs with zero-width spaces that are invisible which fail validation. User doesn't understand why, complains. Enforcing a character set for certain kinds of inputs is a very good thing.

In 26 years of web dev, mostly as a frontend person, I've only seen zero width spaces in three situations - pasting from Word - QA testers being through - devs pranking each other The third one is by far the most common. Word is much better these days and I've not seen that happen in a long time. I wish I saw QA test this stuff more often. The idea that it's common enough that you'd break your UX to handle it bafflin…

Add to that pasting from MS Teams.

Re: HTML Form Validation is underused

#167

The last example is bad. You shouldn'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 one of my big gripes - when apps are trying to get ahead of me with validation or submission. When I'm entering a 2fa code, I don't need a big red error telling me that the code must be 5 digits before I'm even finished. Worse is when they immediately auto-submit upon entering the last digit, so if I made a mistake I can't backspace and correct it

Re: HTML Form Validation is underused

#168

Earlier quoted context omitted.

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

There is no real benefit because the validation rules allowed there are often too limited for real use-cases anyway.

What do you mean there's no real benefit?

You give the same error messages based on whatever custom validation and control the output.

Re: HTML Form Validation is underused

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

Unfortunately the number input is lacking and inconsistent. We’ve always fallen back to JavaScript validation.

Also, many things that look like numbers shouldn't be encoded as such, e.g. credit cards or phone numbers, are not.

E.g. any leading zeros get dropped out of phone number starting with a 0, very common.

Re: HTML Form Validation is underused

#170
post #135

Earlier quoted context omitted.

Why blame it on the user, instead of fixing it? You could remove the zero-width spaces in validation (for eg a phone number).

Or, you know, prevent invalid characters from the get-go. Same thing as validation, but done up-front. (But as I said elsewhere, I'm not talking about phone numbers, I'm talking about amounts)

Because this often makes the input feel broken to the user.

Instead of asserting that "users are too stupid" as you have done earlier, perhaps programmers should be less stupid and write more permissive parsers.

Accessible design is actually pretty hard, and most designers and programmers get this wrong. If you want some good design advice, you can start here: https://adamsilver.io/blog/the-problem-with-live-validation-...

Post reply on HN