I feel like I remember StackOverflow (and related sites) having OpenID login as an option, but I don't see it anymore. I figure they removed it due to low popularity.
True, but vast majority of websites don't do the right thing. So password managers need to manage a database of form input overrides. I worked at a small company building a password manager and it was a bit of a nightmare, we had to allocate support staff resources to handling reports of website incompatibilities.
I worked for a small company that did. The idea was the password manager lived only on your phone, and you'd connect it to your computer in various ways. Notably including our own hardware, USB nub that connected to the phone app via Bluetooth and acted as a keyboard for the device and the app would instruct it to do the keystrokes to enter your saved credentials. Also a browser extension that the app would connect to over websockets (through our relay servers, DH key exchange to encrypt the connection end to end) and the extension would request the app to send down the credentials on demand. Also we were a very early adopter/implementor of FIDO U2F (security keys). The product kinda hinged on the paranoia of the userbase (which I never aligned with, I trust 1Password and cloud sync'd encrypted vaults for example) so it never really took off. It wasn't "my" product, but I worked on it for a few years, right out of school.
What's hilarious is they do have UI for it in about:config "dom.forms.datetime.timepicker". It makes me so angry that it's not on by default. It works fine!
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 has to build their own solution.
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 something in, then edit it down to the correct length.
Very much this. Live re-structuring runs afoul of tons of things you can't predict.
You can validate roughly anywhere, but at the absolute earliest, only re-format on blur. Never earlier. You have no idea what the user might be doing in the meantime.
And even then, I'd strongly suggest not changing what they entered. Change it to a display-only element with nice formatting if you want, but don't screw with their input.
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 26 years of web dev, mostly as a frontend person, I've only seen zero width spaces in three situations
- pasting from Word
- QA testers being through
- devs pranking each other
The third one is by far the most common. Word is much better these days and I've not seen that happen in a long time. I wish I saw QA test this stuff more often. The idea that it's common enough that you'd break your UX to handle it baffling to me.
I'll be one of those guys. I see the invisible whitespace from pasting ALL the time. I've literally dealt with user complaints caused by it three times in the last two weeks! (Usually customer issues don't make it to me unless our support team can't figure it out or suspects a bug)
To be fair, it's not usually that frequent. Just a funny coincidence that I've JUST dealt with it more recently.
"Break your UX" is a vast exaggeration. I'm not talking about phone number fields, to be clear. I'm talking about like numeric amounts, with maybe a negative or decimal point. It's literally just [0-9\.-] but that still requires JS to limit inputs to that.
It doesn't prevent the bad input, it only validates it on submission. Therefore it's on the user to fix it, and if it's from a zero-width space, it's literally invisible. Non-technical users will have no idea what to look for to fix it (i.e. use your arrow keys cursor to see at which character the arrow key doesn't shift visually, and there's the ZWSP). It happens way too often.
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?
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.
The nice thing about the native input is that it is very simple, predictable and flexible. It may be easier to make a better UX on the happy cases but it is very difficult to not add some suboptimal and confusing UX on the less happy cases. Often times it is best just to keep it simple so that the user can easily complete their task rather than adding some "magic" which may backfire and confuse users.
It is surprisingly often that I need to open a text-editor or clipboard-editor to format values before pasting them into apps or websites because they have broken an input field by trying to be magic and failing to consider anything but the happy cases and maybe one or two bad paths.
The exact same problem applies. If I copy "Sep 24 $2412.45" out of a message and you quickly "clean" it to 242 412.45 I may not notice and even if I do it will take a second for me to realize what happened and clean up the value to be the intended amount. If I see the original text in the field it is much more obvious what happened and quicker for me to understand what I need to do to fix it.
> 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.
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).
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.
Or, you know, prevent invalid characters from the get-go. Same thing as validation, but done up-front. (But as I said elsewhere, I'm not talking about phone numbers, I'm talking about amounts)
I would like to allow people to copy-and-paste text in, and then edit it. That could be a longer text that has the amount in it (but also some unrelated numbers).
Because this often makes the input feel broken to the user.
Instead of asserting that "users are too stupid" as you have done earlier, perhaps programmers should be less stupid and write more permissive parsers.
I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users.
To clarify, we get _asked_ by our users to implement fields that limit input to help them avoid mistakes. Our QA and UX teams agree. This isn't a unilateral engineering decision.
Yes, you want to provide guidance, but without getting in the way.
That's why I was suggesting letting the user paste in these 'wrong' characters, but offering help in removing them.
Of course, that's a trade-off. And it's more annoying to design and implement than just forbidding those characters from entering the input field in the first place.
I'm not being user hostile. I'm being cognizant that the skill levels of users is extremely wide, and to best serve everyone from a UX standpoint, it's best to limit the characters accepted in the input. It protects the user, helps them avoid mistakes.
From reading your comments, you're extremely user hostile and I hope to not come across anything you work on because they are the very definition of antipatterns
Please read my other comments. I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users.
> what's crazy is both of those still don't disallow non-numeric input
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.
This page explains all that: https://caddyserver.com/docs/running. Ultimately it depends how you installed Caddy and how you're running it (Docker vs Systemd vs directly via CLI, etc).
Caddy maintainer here; could you be more specific about the usecases you think look like a nightmare? We're always looking to improve config ergonomics, but we need specific feedback.
Former Caddy user here but we converted to Kubernetes and Ingress-Nginx replaced it.
I wish we could have multiple config files that would get combined together at run time, bonus points for "All files ending with *.caddyfile in /dir" would get loaded.
Why might you ask? GitOps. We kept Caddyfiles in Git, but JSON would get corrupted when being edited. If they were individual files, it probably would have resulted in less headache and easier maintenance.
Caddy maintainer here; hiding things doesn't make sense, some people do need to see that information, namely users of the API who perform scripted config changes on their running servers. The Caddyfile is pretty up-front-and-center, so I don't know where the confusion is coming from.
