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

321–330 of 343 posts

Re: HTML Form Validation is underused

#321

Post by DaiPlusPlus »

chii wrote: post #318
everdimension wrote: post #227

Earlier quoted context omitted.

I think the problem here is not as much with the absence of custom styling, because you can quite easily read the native "validity" state of the input and render it however you want. The problem is that it's quite tricky to correctly subscribe to the changes of this validity state. There are indeed some validity events being dispatched, but unfortunately not always. Updating form state programmatically (such as calli…

I think form validation should remain an app implemented part of a web form, rather than natively built into the browser. The majority of the work in form validation is not in the validation of the data, but in the UX and interaction, display and update of state. There's no generic way to handle it, as it's very dependent on the app itself. Keeping the browser smaller and cleaner, with less logic seems to be a better…

> Keeping the browser smaller and cleaner, with less logic seems to be a better idea

That idea died sometime around 15 years ago.

Chromium can probably be best-described as a kind-of user-mode OS at this point.

Re: HTML Form Validation is underused

#322

Post by tsimionescu »

SoftTalker wrote: post #283
tsimionescu wrote: post #279

Earlier quoted context omitted.

People want to style things to match their page, exactly because consistency is part of usability. Especially given the limitations of browser form validations, you will absolutely need your own validations in addition to any browser validations you use. But your own validations will look different from the browser-provided ones, at least on some browsers. Which will confuse users, hence decreasing usability. And thi…

News flash, every site doing things their own way is one of the core usability problems on the web. Designers love it. Users hate it.

I think consistency within an application is far more important than consistency across applications. And even if it were true that users hated the lack of consistency, it would fall on deaf ears: the web page developers can only influence their own page. They can't make Google or Mozilla or Apple come up with an actually usable error model, or any kind of good UI in general, so the only chance they have is to create a good UI for their own page, and hide the horrible defaults that each browser is reinventing.

Re: HTML Form Validation is underused

#323

Post by [deleted] »

Sander_Marechal wrote: post #151
skrebbel wrote: post #142

Earlier quoted context omitted.

The `required` attribute, which this article is about, is an HTML5 thing and first appeared in browsers in 2010-2011. So sure, not brand spanking new, but the web was already used to write modern apps. There's no good reason for the validation features to be so shabby.

Even 'required' doesn't work properly. Browsers do very odd and inconsistent things when your required field is hidden when submitting. Like in a basic tabbed or multi-step form.

[deleted]

Re: HTML Form Validation is underused

#324

Post by ozim »

zelphirkalt wrote: post #316
ozim wrote: post #128

Because it sucks. It does not translate with the application but with browsers settings, it doesn’t style or fit any design. It looks differently on different browsers and it is really hard to explain to stakeholders “this is from browser I don’t have control over it”.

And your application should be looking at ... the browser settings. I could see a case, if a user decides to somehow make a single website use a different language than the others. I guess it would be a browser's job to have specific languages for specific websites.

It works for presenting or selecting initial language. Even that is debatable because some big players don't even care about that and present language based on location.

Explaining to people they should go and change their browser settings is major hassle.

Re: HTML Form Validation is underused

#325

Post by raxxorraxor »

MaxBarraclough wrote: post #305
raxxorraxor wrote: post #270

Earlier quoted context omitted.

The standard HTML components are ancient and not very usable. People like to complain about JavaScript on websites, but they often don't know in what a bleak world they would live.

I'm not sure about that, plenty of HackerNews users see its minimal and functional UI as a feature not a bug. I wish there were more lightweight websites, none spring to mind other than HackerNews, SourceHut, and Pinboard.

I love that as well, I hate bloated sites just as the next one here.

But for any more complex form with dynamic content, JS is still inevitable. I guess for HN the input form at the bottom is enough. But Algolia uses a custom input component already.

Re: HTML Form Validation is underused

#326

Post by zelphirkalt »

ozim wrote: post #324
zelphirkalt wrote: post #316

Earlier quoted context omitted.

And your application should be looking at ... the browser settings. I could see a case, if a user decides to somehow make a single website use a different language than the others. I guess it would be a browser's job to have specific languages for specific websites.

It works for presenting or selecting initial language. Even that is debatable because some big players don't even care about that and present language based on location. Explaining to people they should go and change their browser settings is major hassle.

Automatic language selection based on location is an anti-pattern. If I am traveling, I don't suddenly switch my brain to another language. Whoever writes websites like that doesn't properly think about it.

Re: HTML Form Validation is underused

#327

Post by pmontra »

francislavoie wrote: post #225
kevincox wrote: post #223

Earlier quoted context omitted.

What if I copy something but accidentally get another couple words one of which is a number. For example copying from a chat app and get the date with the message. Then my "Sep 24th 416-555-1234" input which, would have been very easy to fix, becomes 244-165-5512 34. It will take me a few seconds to realize what has happened, identify where the intended phone number starts and remove the accidentally pasted digits. T…

I was talking about numerical amount fields, not phone numbers or dates or credit card numbers. Those are different things entirely. FWIW if you're copying text on Android, you can tap the clipboard popup to edit the clipboard item before pasting it elsewhere.

> FWIW if you're copying text on Android, you can tap the clipboard popup to edit the clipboard item before pasting it elsewhere.

I never noticed that after 13 years of Android. I checked that now and I could not find a way to do it. Samsung's keyboard has a way to look at the clipboard but I could not edit them. Swiftkey does not. Maybe Google's keyboard? It's not on my phone. I looked at a couple of videos but they don't look anywhere like my phone. Not a feature to invest much time on it. If I have to edit the clipboard and I can't do it where I want to paste it, I open an editor and paste it there.

Re: HTML Form Validation is underused

#328

Post by francislavoie »

pmontra wrote: post #327
francislavoie wrote: post #225

Earlier quoted context omitted.

I was talking about numerical amount fields, not phone numbers or dates or credit card numbers. Those are different things entirely. FWIW if you're copying text on Android, you can tap the clipboard popup to edit the clipboard item before pasting it elsewhere.

> FWIW if you're copying text on Android, you can tap the clipboard popup to edit the clipboard item before pasting it elsewhere. I never noticed that after 13 years of Android. I checked that now and I could not find a way to do it. Samsung's keyboard has a way to look at the clipboard but I could not edit them. Swiftkey does not. Maybe Google's keyboard? It's not on my phone. I looked at a couple of videos but they…

I'm using stock Android, Pixel 8 Pro. Highlight text then tap "Copy". See a toast in the bottom left. Tap on it (not the X) and a little text editor applet opens up. Here you can edit the text and save it, updating the value in the clipboard. Then using Gboard, it has clipboard history so you can see and paste the specific recent item from the past hour that you want. (Unfortunately it can't be edited after initially copying although you can long press them in the Gboard menu to pin for longer or delete them).

Re: HTML Form Validation is underused

#329

Post by braiamp »

chii wrote: post #318
everdimension wrote: post #227

Earlier quoted context omitted.

I think the problem here is not as much with the absence of custom styling, because you can quite easily read the native "validity" state of the input and render it however you want. The problem is that it's quite tricky to correctly subscribe to the changes of this validity state. There are indeed some validity events being dispatched, but unfortunately not always. Updating form state programmatically (such as calli…

I think form validation should remain an app implemented part of a web form, rather than natively built into the browser. The majority of the work in form validation is not in the validation of the data, but in the UX and interaction, display and update of state. There's no generic way to handle it, as it's very dependent on the app itself. Keeping the browser smaller and cleaner, with less logic seems to be a better…

Checking if a string is a email (or at least looks like one), if it's a number, etc. is such a cheap processing, that setting up and tearing down a connection to the server to process it is a waste of resources. Client side validation has its uses, it's more responsive. The problem is that we want all these custom behaviors when it's actually some rudimentary data input validation.

Re: HTML Form Validation is underused

#330

Post by braiamp »

kaoD wrote: 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…

Interesting, because for my apps, I implement all those validations. The form wide validation are done on server. Basically I have a bunch of layers of validation that leverages everything. Chrome having a shoddy unaccessible design is Chrome problem, I would file a bug report.

> it's the spec

This one? https://html.spec.whatwg.org/multipage/dom.html#concept-elem...

I don't see anything that defines how validation messages should be presented (not even that they should be present)

Post reply on HN