181–190 of 343 posts
Html form validation is great. There's just one gigantic catch: It doesn't work in Firefox for Android. https://bugzilla.mozilla.org/show_bug.cgi?id=1510450
The best native HTML validation is server-side validation. The only downside: the user has to wait 300ms.
And he loses his page state if there is an error. You have to do server-side validation regardless, but client-side validation can be a lot more pleasant for the user. I used to think it doubled your workload to do both, but if you are using JS-free client-side validation, I think that the server can just return an HTTP error guilt-free for any invalid input that the browser will catch. It’s a pretty good compromise…
No, you can handle that on the server too, easily, since you can fill the form with the last known state upon page loading.
Html form validation is great. There's just one gigantic catch: It doesn't work in Firefox for Android. https://bugzilla.mozilla.org/show_bug.cgi?id=1510450
Earlier quoted context omitted.
The native date input is terrible. Not the actual native control, which is usually okay, but the field itself. You can't even format the date! That's the number one reason I always use some datepicker library in combination with a regular text input.
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…
I always keep my OS and browser in English (makes searching for error messages sooo much easier) but I hate that I need to change my OS settings just to get Firefox to display the date in a proper way on some site.
Earlier quoted context omitted.
> (Also kinda anoying to have to duplicate this tho) Security and convenience are like space and time, you can't move one without transformation of the other.
You could fill those setCustomValidity() calls in the client with rule-sets generated on the server. even re-fetch them from the server on each input change in the client or just ditch the whole thing and do it in htmx :->
The best native HTML validation is server-side validation. The only downside: the user has to wait 300ms.
And he loses his page state if there is an error. You have to do server-side validation regardless, but client-side validation can be a lot more pleasant for the user. I used to think it doubled your workload to do both, but if you are using JS-free client-side validation, I think that the server can just return an HTTP error guilt-free for any invalid input that the browser will catch. It’s a pretty good compromise…
Earlier quoted context omitted.
It's not a security feature, it's a UX feature.
I'd argue it's often an anti-feature. These validation at input can be super annoying when you're copy-pasting your strings from other sources, and want to edit them in textbox in-place. Especially if you're on your phone. I've be frustrated by this on numerous websites, a lot.
Earlier quoted context omitted.
This is for a closed system that unfortunately sometimes is supposed to be available outside[1] - a touch screen panel UI for (big[2]) embedded system. It's hard to impossible to properly guide OS outside the browser regarding what keyboard we want at different points in time unless we end up also implementing custom keyboard plus some way to talk with it from JS. Previously we used a Chromium extension that could by…
Isn't this use case already solved by phone browsers? Layouts are controlled via the inputmode attribute. Positioning the keyboard should be something solved by the host environment.
2. "Solved by host environment" in practice means "worse user experience" as pretty much all of them simply use lower portion of the screen.
In comparison, the current draggable on screen keyboard I spent significant amount of time getting working allows the worker to drag the keyboard around if it overlaps a piece of information they need, as well as takes comparatively little space on screen enabling workers to better see what they are manipulating.
Earlier quoted context omitted.
The {4} is being applied to the whole group which includes a .* Isn't that correct?
Yep, and the .* means "0 or more of anything", so it's 4 or more groups that each end with a letter. They can be consecutive or not and a group can be a single letter but doesn't need to be - so whatever the failure was, it wasn't that (or the regex was typo'd here to be correct instead of what was actually on the site).