141–150 of 343 posts
The best native HTML validation is server-side validation. The only downside: the user has to wait 300ms.
You've got tech stacks and cloud services that will put you within 20ms of 99% of your users.
Server side everything is still the safest possible bet you can make.
In an all honest reply, is that the people that writes these specifications, live disconnected from the reality, they don't use the stuff they specify. That stuff works for very simple things, but then when your forms evolve you realise you will be better off just writing the whole thing yourself.
Most of the forms features are from the early 90s. You're not working in the same millennium as some of the specification writers.
Earlier quoted context omitted.
On Android, the date picker widget is fiddly to use for selecting distant dates, like date of birth. Not impossible but requires many many taps.
That's an implementation issue, not a specification issue. The specification just suggests the user is shown a date picker.
Earlier quoted context omitted.
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.
But what's crazy is both of those still don't disallow non-numeric input unless you use JS to reject keystrokes and intercept paste. HTML form validation is so incomplete and limited, every time I look at it I want to scream cause wtf there's so many just totally obvious things we need that don't exist by default and we need to reinvent the wheel. Native date and time inputs are still garbage so every UI framework ha…
Which is really nice for copy pasting. For example, I have a number with spaces in it, and when I paste I get nothing or only until the first space because someone decided I'm not allowed to have non-numericals in the input field at anytime.
Earlier quoted context omitted.
The problem here is that sometimes users and copy pasting from another document and that comes in arbitrary formatting, not the one enforced by the input element. For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit.
> For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc > > It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit. How is that more pleasant than a textbox which automatically removes the extra characters?
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 found this very extended with "date" input. It seems that every single frontend library has its own date widgets, and lots of them look awful in small screens. You have to add a JS and CSS just for that widget, some depending on jQuery. True, some of them are very configurable, but with the tiny cost of " " you have a widget that looks decent and native everywhere, probably cover your needs, and you can forget abou…
In most cases, GDS now use just 3 text fields for day, month and year, but recommend pickers for dates close to today's date e.g. for booking an appointment, because a picker is easier if you don't know the exact date without reference to a calendar.
Sadly they don't currently have a recommended picker, but there's a useful discussion of what has been tried here:
https://github.com/alphagov/govuk-design-system/discussions/...
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 found this very extended with "date" input. It seems that every single frontend library has its own date widgets, and lots of them look awful in small screens. You have to add a JS and CSS just for that widget, some depending on jQuery. True, some of them are very configurable, but with the tiny cost of " " you have a widget that looks decent and native everywhere, probably cover your needs, and you can forget abou…
Earlier quoted context omitted.
This is particularly annoying on mobile since on-screen keyboards won't adjust to an email input layout and autocorrect will screw up basically any email address as soon as a "." character triggers autocomplete to commit it's guess.
And password managers will not fill in the credentials correctly.