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.
HTML Form Validation is underused
11–20 of 343 posts
Re: HTML Form Validation is underused
#12After reading all this, I think I'd still choose to do it away from the browser built in capabilities. I'd rather have full control over the process and the design than rely on the limited capabilities of browsers.
The browser is programmable; at this point they should stop getting clever about adding built-in functionality and instead just expose better ways to use the browser as a dumb UI toolkit.
Re: HTML Form Validation is underused
#13simply adding required is all you need.Not required=true The omission is equal to required=false. No one really write required=true, they just add the attribute `required` only by its self. This is one of the odd quarks about html attrs Same is true for things like disabled ect https://developer.mozilla.org/en-US/docs/Glossary/Boolean/HT... > The strings "true" and "false" are invalid values. To set the attribute to…
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.
Re: HTML Form Validation is underused
#14One of the things I dislike about HTML form validation is it starts running from page load. So if e.g. you tie error state formatting to it, the form loads up with a bunch of errors which may be intimidating to the user.
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.
Re: HTML Form Validation is underused
#15After reading all this, I think I'd still choose to do it away from the browser built in capabilities. I'd rather have full control over the process and the design than rely on the limited capabilities of browsers. The browser is programmable; at this point they should stop getting clever about adding built-in functionality and instead just expose better ways to use the browser as a dumb UI toolkit.
Couldn't disagree more. Browser features can be much better at handling edge cases: disability, localisation, unusual devices, different input methods, weird screen sizes, etc... rather than hoping every developer does it right, building that in is more efficient and consistent. The common cases should be handled really well by browsers.
Re: HTML Form Validation is underused
#16That's nice, I'll use that next time. Although it always feels kind of bad to write client side validation code because you're going to have to do the same checks on the server side anyway.
Necessary because a user can always inspect > modify the HTML.
Re: HTML Form Validation is underused
#17One of the things I dislike about HTML form validation is it starts running from page load. So if e.g. you tie error state formatting to it, the form loads up with a bunch of errors which may be intimidating to the user.
There is the :user-invalid pseudo-class that lets you avoid this to some extent, but it has some inflexibility that may mean it isn't enough, depending on your use case.
https://developer.mozilla.org/en-US/docs/Web/CSS/:user-inval...
Re: HTML Form Validation is underused
#18The 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.
Re: HTML Form Validation is underused
#19After reading all this, I think I'd still choose to do it away from the browser built in capabilities. I'd rather have full control over the process and the design than rely on the limited capabilities of browsers. The browser is programmable; at this point they should stop getting clever about adding built-in functionality and instead just expose better ways to use the browser as a dumb UI toolkit.
Couldn't disagree more. Browser features can be much better at handling edge cases: disability, localisation, unusual devices, different input methods, weird screen sizes, etc... rather than hoping every developer does it right, building that in is more efficient and consistent. The common cases should be handled really well by browsers.
I couldn't disagree more; it might be good for disability but for localization, unusual devices, different input methods, weird screen sizes I have never seen that well executed by browsers. I almost always prefer a more full-featured alternative from a standard framework than whatever is lowest-common-denominator feature in a browser -- which also, depending on the browser, may or may not work the same or may or may not even exist.
The browser should provide low-level capabilities and let developers build the high-level functionality from it.
This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be.
Re: HTML Form Validation is underused
#20That's nice, I'll use that next time. Although it always feels kind of bad to write client side validation code because you're going to have to do the same checks on the server side anyway.
I find it sad that so many frameworks leave the developer to duplicate server-side and client-side validation. There are obviously some things you can't reasonably validate on the client, but I'd like to see more automated ways to take backend constraints and check them on the client too. Ideally constraints would also propagate from model definitions, so there could be a single source of truth for "what phone number…
One of the compelling reasons to use Javascript-based frameworks like nextjs or remix.run is that you can reuse the same logic + types on the frontend and backend.
With Typescript, this is now my preferred way to build full-stack sites.