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

211–220 of 343 posts

Re: HTML Form Validation is underused

#211

Post by cxr »

DaiPlusPlus wrote: post #107
cxr wrote: post #102

Earlier quoted context omitted.

[flagged]

I agree with you 100%; I hate it when websites think they’re being trendy by using undraggably-thin scrollbars or try to subvert the UA’s password-manager (banks…) or naively think they can block users right-clicking or copying images. To clarify my position: I agree that UAs should be free to show validation messages as-appropriate for the user (I.e. those popover hints) but it is because Google decided to stylise t…

You're talking about millions of dollars of engineering resources to implement what not only doesn't matter, but is probably actually harmful in comparison to the status quo (however ugly that is). And that's just on the implementation side. Now consider the tens of thousands of downstream developers who are going to suck up more resources from their clients because browser developers offered them a new bauble and some knobs to tweak. All going towards something that shouldn't even exist.

Re: HTML Form Validation is underused

#212

Post by micromacrofoot »

guappa wrote: post #202
ximm wrote: post #198

Earlier quoted context omitted.

I never really understood why people want to style stuff like this. I like how you can express yourself by using colors and layout and stuff like that. But at some point usability is more important than branding.

> 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

Re: HTML Form Validation is underused

#213

Post by everdimension »

donatj wrote: post #3

You gotta be careful about going overboard with it. Recently I was trying to get a refund on Groupon because the company I'd bought a Groupon for was under new management that refused to honor my groupon. The form had a stipulation "minimum of 15 words". Try as I might, I could not get the form to pass validate until I inspected the HTML. \w - word characters \b - word boundaries \s - white Literally zero allowance f…

That's actually a good argument for the point I was trying to make. Existing validity attributes such as "pattern" are cool, but not enough.

E.g. the "repeat password" example is actually achievable without "setCustomValidity" by using the "pattern" attribute. For that, you would have to dynamically construct a RegEx out of the value from the first input. I didn't want to make the article too long by comparing the solutions, but the point is, with the "customValidity" you see how much more eloquent and easier to read the validation is. So a nicer API here makes all the difference

The "15 word minimum" constraint would look so much nicer as "value.split(/\s+/).length >= 15".

Re: HTML Form Validation is underused

#214

Post by whoisthemachine »

recursive wrote: post #5
donatj wrote: post #3

You gotta be careful about going overboard with it. Recently I was trying to get a refund on Groupon because the company I'd bought a Groupon for was under new management that refused to honor my groupon. The form had a stipulation "minimum of 15 words". Try as I might, I could not get the form to pass validate until I inspected the HTML. \w - word characters \b - word boundaries \s - white Literally zero allowance f…

I don't think this is particularly pertinent to HTML validation. This is true of any type of validation. The same rule could have been applied on the server, and then you would have had no hope.

Exactly. My rule of thumb is "don't add validation until there is absolutely no better way and you absolutely must restrict this input."

Re: HTML Form Validation is underused

#215

Post by otherme123 »

Sander_Marechal wrote: post #184
otherme123 wrote: post #161

Earlier quoted context omitted.

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

If my entire application used YYYY-MM-DD everywhere, it can be very confusing for users when the input suddenly uses something else. And often the locale or system settings are incorrect anyway. When I an working on a Dutch site with a Dutch locale and lang settings, then dates should be shown according to the Dutch locale, not according to whatever system of browser locale there is. I always keep my OS and browser i…

If it works for you, I guess it's OK.

My apps usually deal with non-technical people (thus ISO in the browser input is out of the question), and sometimes spread at least between Europe and US (so people would enter MMDDYYYY and DDMMYYYY, and keep in mind that some dates work validate for both formats, namely every 12 first days for each month). Behind the scenes everything is ISO and UTC, but everyone gets their preferred format in the frontend.

I'm not getting your Dutch example. If I'm in the US and use MMDDYYYY almost always, and want to access some Dutch site, what date format would you show me in the input form? DDMMYYYY only because the backend is hosted in Europe? You will get wrong dates (e.g. 11/1/2024 for the first day of november, your system will store 11th of january) for at least half the US visitors.

Or maybe you are talking about "dates displayed" instead of "dates input", which is a different problem?

Re: HTML Form Validation is underused

#216

Post by everdimension »

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

It does suck, but I think not for the reasons you mention.

I truly believe a nicer API would motivate developers to use it, and if native validations satisfy the product requirement, their styling does become a lesser concern.

But surely styling is still important, but another great topic to write about is the fact that you actually can opt-in to showing native validity errors in a custom way!

Re: HTML Form Validation is underused

#218

Post by oneeyedpigeon »

dagw wrote: post #204
ximm wrote: post #198

Earlier quoted context omitted.

I never really understood why people want to style stuff like this. I like how you can express yourself by using colors and layout and stuff like that. But at some point usability is more important than branding.

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 "branding" or "function"? IMO, an error modal is nothing to do with company branding, etc. — it's not even part of your document, it's the browser's responsibility. The browser can decide to do something completely different from showing a modal as far as its concerned, so you shouldn't make any assumptions. Your responsibility ends at declaring what valid data is.

Re: HTML Form Validation is underused

#219

Post by fkyoureadthedoc »

epolanski wrote: post #168
gregoriol wrote: post #158

Earlier quoted context omitted.

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.

I've found it more annoying to mess with the browser validation API and using setCustomValidity/reportValidity etc. than to just use other validation libs. Ideally I'd use whatever library I want and they would call setCustomValidity for me though.

Using the related pseudo classes :valid, :invalid, :required, :optional is nice, but until last year you still had to do custom logic there because :user-valid/:user-invalid weren't implemented outside of Firefox. That created additional work and was annoying.

Re: HTML Form Validation is underused

#220

Post by kevincox »

francislavoie wrote: post #122
Dwedit wrote: post #121

Earlier quoted context omitted.

I used to write those fancy textboxes that reformatted your input as a phone number as you type, and intercept paste, and all that. But then it turns out that you really do want a free-form text input. Let people paste text in, edit their text freely, then let it validate afterwards. When it validates, then reformat it. For example, text boxes with length limits. These are awful. It messes with your ability to paste…

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 most cases when you are accepting a numeric value it is best to just strip anything that isn't 0-9 then run validation on just the digits. There are some exceptions like phone numbers which may need + prefixes and similar but you can adjust these rules.

What I have found to work well is when the user unfocuses the input field or on submit strip everything but expected values then validate. If you want you can format the value at this time too (and the formatting won't interfere with text input).

If you want to get really fancy you can strip and format as they type and be careful to keep the formatting "virtual" such that the user is only editing the raw digits but this is very tricky to get right on all platforms and support all expected native editing UX. But even in the best cases this can have bad edge cases. For example the user pastes some text but it happens to have multiple numbers in it, if you eagerly strip and format what is left for the user will be these two numbers mushed together with misplaced separators or similar. If you let them paste, remove the unintended stuff, then format on blur this just works and is understandable.

Post reply on HN