Live data from Hacker News

HTML Form Validation is underused

expressionstatement.com

231–240 of 343 posts

Re: HTML Form Validation is underused

#231

Earlier quoted context omitted.

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…

With this kind of take - why do we need different applications at all?

UX/UI is solved just use spreadsheet grid, you can do everything in spreadsheet and you will have exactly the same interface/way of doing things.

It is not a joke - I personally have like 80% of things in a spreadsheet (don't get me started what kind of spreadsheet abuse I have seen in my career). But I do understand that lots of stuff can be done much more efficiently with tailored controls and not everything is couple of drop-downs/text boxes.

Re: HTML Form Validation is underused

#232
post #133
post #125

Earlier quoted context omitted.

That's an implementation issue, not a specification issue. The specification just suggests the user is shown a date picker.

You’re technically right but that doesn’t matter. That you’re correctly using html forms won’t quickly lead to browser improvements.. so the result is that users will hate your forms. Users/your customer might possibly even think that you’re to blame, and not $browserVendor.

I’ll go one further and say that the customers are absolutely justified to blame the developer instead of the browser. If a developer knowingly chooses a built-in form control whose common implementations are bad for their users, how are they not at fault for the resulting experience?

“This site only uses functionality provided by the HTML spec” is not a useful goal in and of itself. Using the right tool for the job, which might be JavaScript, is always more important.

Re: HTML Form Validation is underused

#233

Ya'll may want to checkout Valibot¹ or Zod² in conjunction with something like React Hook Forms³ or the more agnostic Tanstack Forms⁴. Really sweet form validation that's concise but as precise as you want it to be. The problem with vanilla form validations are (1) they're so basic that it's table stakes for any library or framework in this space, even ChatGPT can do it well, (2) there's an enormous amount of other v…

> there's an enormous amount of other validation scenarios they don't cover

Can you provide examples of those? Genuinely interested as I'm on a quest of creating a list of recipes that show that native form validation can be just as capable as custom validation libraries

Re: HTML Form Validation is underused

#234
post #204

Earlier quoted context omitted.

But at some point usability is more important than branding. I have never worked for any company or organisation that believed this. Most clients will send you their branding guidelines before sending their feature requests. If they get to choose between adding a new feature, improving usability or making sure everything follows the branding, they will choose the branding every time.

I think you're exaggerating here. I recognise the "branding is more important than usability" approach, but the OP specifically said "at some point". Have you ever worked for a company that forced a design decision knowing it would prevent anyone from using the product? I suspect not; there will always be some point. The issue here is, at what point does usability take precedence. Does input validation fall under "br…

It 1000% falls under branding. If you don't make errors consistent across browsers / platforms your support staff will politely but firmly burn your house down. There's no such thing as your responsibility ending and throwing your hands up when you're a company who has to do end-to-end support of your product.

Having as little native anything means you go from n sets of documentation to 1.

Re: HTML Form Validation is underused

#235
post #206

Earlier quoted context omitted.

From reading your comments, you're extremely user hostile and I hope to not come across anything you work on because they are the very definition of antipatterns

It's a decimal number field. There's no reason to have any other characters than [0-9\.-]* You're overreacting. You're attacking me for no reason.

Except if one copied it and it has a space in the beginning and your amazing script won't let one paste it.

Re: HTML Form Validation is underused

#236
post #202

Earlier quoted context omitted.

> usability is more important than branding. Said no designer ever. At work our design team came up with buttons that are 10x10 pixels on my screen. They are used to change pages (like on mobile, but this is a desktop program), the scroll events are ignored by design, so you either click the tiny buttons (which are slightly darker gray than the dark background) or you simulate a finger swipe via drag and drop with th…

plenty of designers say this, often company leadership is the one pushing them to style everything because everyone else does

Well the ones I've worked with couldn't care less.

Of course they love to show off how good they are to the poor disabled people, but that doesn't mean anything until some government reminds us that we are in breach of contract unless we make our GUI accessible.

Re: HTML Form Validation is underused

#237
post #116

The best native HTML validation is server-side validation. The only downside: the user has to wait 300ms.

And he loses his page state if there is an error. You have to do server-side validation regardless, but client-side validation can be a lot more pleasant for the user. I used to think it doubled your workload to do both, but if you are using JS-free client-side validation, I think that the server can just return an HTTP error guilt-free for any invalid input that the browser will catch. It’s a pretty good compromise…

Great answer, exactly! Client-side validation isn't meant to remove the need for the server-side checks

Re: HTML Form Validation is underused

#239
post #8

Earlier quoted context omitted.

They've used `required={true}`, not `required="true"`, which is JSX, not HTML. The one with curlies isn't even valid HTML. In the old HTML spec, the correct value, if you wanted to set a value, was to set `required="required"`, but these days the spec is looser since it tries to conform to the web, not the other way around.

Even in jsx its not required to add a boolean value. Unless you are passing in a var as a prop in which case sure. But that didn't look like it was the case in these examples.

> Even in jsx its not required to add a boolean value

Absolutely true! But I like to do it because I personally think it reads more nicely and is more explicit and that's what I do in all my projects. But it is indeed a matter of taste and I have nothing against code that follows the convention to omit the "true" value.

Re: HTML Form Validation is underused

#240
post #31
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.

I think type=number is a mistake as it is too generic. It is difficult to get proper validation, UI and error messages.

It should be split into:

type=integer so the keyboard does not allow anything besides 0-9

type=decimal so the keyboard also allows decimal dot/comma and a fixed number of decimals!

type=float which allows for scientific notation, e.g. 1.2e42

Post reply on HN