Live data from Hacker News

HTML Form Validation is underused

expressionstatement.com

71–80 of 343 posts

Re: HTML Form Validation is underused

#71

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…

> 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 brows…

[deleted]

Re: HTML Form Validation is underused

#72

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…

This is one of these things that sounds perfectly logical -- you want all UI components to look and behave the same across all applications and all websites -- but that is more theoretical than practical.

If you built an app that used just what the browser gives you and nothing more, you're leaving so much functionality on the floor. Having more expressive power often makes things simpler -- using more complex UI controls has allowed me to eliminate whole pages from my application. Users are happier and more productive.

Browser UI implementations can't do one thing that is vital: compete.

Re: HTML Form Validation is underused

#73

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…

For that matter, styling a select (single) isn't quite the walk in the park it should be.

Re: HTML Form Validation is underused

#74
post #54

Earlier quoted context omitted.

I had to recently make sure that we do not use any of the more complex input elements, because we need to drive them from on-screen keyboard that for various reasons is also implemented in-page. And that means it's barely doable with normal inputs, the special ones support even less events.

> because we need to drive them from on-screen keyboard that for various reasons is also implemented in-page There's your problem right there. Can you expand on the reasons? It seems like very bad practice for a website to provide it's own "keyboard" instead of using the system keyboard.

This is for a closed system that unfortunately sometimes is supposed to be available outside[1] - a touch screen panel UI for (big[2]) embedded system.

It's hard to impossible to properly guide OS outside the browser regarding what keyboard we want at different points in time unless we end up also implementing custom keyboard plus some way to talk with it from JS. Previously we used a Chromium extension that could bypass some of the issues because it had privileged access and thus could send "secure" events.

EDIT: For some extra context - for reasons of ease of use, we want the keyboard of appropriate type (numeric, qwerty, other specialized layouts) to show in position related to actual input field, not take entire lower part of the screen like typical on-screen keyboards. For dealing with possible edge cases or otherwise making it more accessible, we also provide for the keyboard to be draggable by user.

[1] Sometimes it's accessed externally instead of in-person, for various reasons this means we have both the ability to open the web interface and use VNC.

[2] By big I mean we have a complete PC running Linux there, with intel CPU/GPU and an SSD

Re: HTML Form Validation is underused

#75

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…

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...)…

I don't see what difference it makes whether you use some component built into the browser or some component built on top of the browser.

This article already starts out with how many ways you can screw up this built in browser feature. I bet you didn't even notice that the article examples were slightly broken. The "fix" shows the error when you press submit but doesn't highlight the field in red like if you backspaced it to empty. This is something my validation code does automatically and correctly.

Re: HTML Form Validation is underused

#77

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.

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

How so? The backend ALWAYS validates. No communication necessary, whether or not the frontend also validates doesn't matter to the backend. Frontend validation is to improve user experience, nothing more.

Re: HTML Form Validation is underused

#78

Earlier quoted context omitted.

This is one of the main reasons people started using JavaScript, to show errors only after a form has been “touched” or right before it is submitted.

A bit perplexed by your comment. That wasn't a main reason people started using javascript. I even remember when people started evangelizing client-side validation in the mid-2000s. Javascript was already a normal tool used in web apps by then, and most web developers would regularly be adding javascript to their apps. Back then it was a bit of a pita as you had all sorts of gotchas with javascript memory leaks by re…

probably they mean why people started using JS in form validation, and not JS altogether, although agree that isn't the reason either.

Re: HTML Form Validation is underused

#79
post #77

Earlier quoted context omitted.

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.

> 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. How so? The backend ALWAYS validates. No communication necessary, whether or not the frontend also validates doesn't matter to the backend. Frontend validation is to improve user experience, nothing more.

>Frontend validation is to improve user experience, nothing more.

and to reduce server load.

Re: HTML Form Validation is underused

#80

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…

> they said to me "Yeah, well HTML is kinda old, it's not really used anymore"...

> I'm sure I've said plenty of stupid things when I was green but I hope no one remembers them like I remember this one. It lives rent free in my head.

I'm doing gigging while my product is gaining traction. Last week, I received this verbatim rejection for a PR review at a client, who's oldest developer is 27:

"No, we don't want all the logic in the same place. You must split the logic up"

This is also one that will take up valuable space in my head till the end of time :-(

(PS. Yes, I split the logic so that it was evenly balanced in 3 different programming languages, instead of having the entire logic in C# alone)

Post reply on HN