. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
Funny that you mention it. Loosing form data on page refresh or clicking "back" button was a problem on the Web until browsers started keeping form state along with page history. Suddenly millions of websites got this new feature without actually doing anything differently. But that was only possible because page transfers were semantic. Frameworks of that time that tried to manage their own form state (like ASP.NET WebForms) didn't have real page transfers, so they didn't get this "upgrade" and currently are significantly worse off in terms of usability.
. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
This was fixed in browsers years ago when they started keeping form state along with page history. I can refresh this page, go back and forth in history, and this text box will keep my comment. Ironically, websites that tried to be clever about form state management and faked page transfers (like ASP.NET WebForms) didn't benefit from the fixes and currently are significantly worse off in terms of usability than websites that used vanilla forms.
> If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
This really shouldn't be a problem for anything other than file inputs. If someone's form is losing submitted information on a validation failure when using an actual HTML submit, then I find it pretty unlikely that they're doing a good job of AJAX submission.
It also results in ugly rendering issues with browsers that save previously submitted form data, overlaying it on top of the placeholder text or replacing it even if it's the wrong data for that field type.
Though I have rarely faced crashes, the offenders on my side are the website themselves.
For example, after going through all the steps, the website decides to not accept my form because of some JavaScript issue or server issues (such issues either take you to a new page where pressing back button clears all your text)
That's why I started saving the text in a text file before submitting. :)
You need to be smart about this though, I don't want it to look like a live/interactive form has worked for example - updating derived data on the page - if it's then going to turn out that actually the server had an error or there was network trouble, and it all gets undone (or worse I close the page/navigate away not realising at all).
> My full response also wasn't submitted (and lost), so I'm trying to recreate part of it here.
Just an aside, that's exactly why I installed browser extension "Lazarus: Form Recovery" years ago. Let's me easily recover/reuse anything I typed into a form previously. Hasn't been updated since 2014 (Chrome web store) but works fine.
You need to tell the user that, though, even if it's just a calming progress indicator or "Saved." label that appears a little after making changes, or a dummy "Save" button they can click.
People have spent years developing habits to defend themselves from crappy web forms. They're not going to let go of those habits without a long adjustment period.
>The form cannot be submitted until the user fixes the error, so the server shall not receive an excessively long text or password
Seems like win/win for everyone. In-spec, less confusing for users, and doesn't change behavior for normal form submissions (JS submitters are clearly opting out of browser safety nets).
I think this is referring to the server round-trip -- form submit, server-side validation, "you have to specify a color for your widget" and everything on the field is blanked out because the server didn't fill in the default values into the form based on your previous submission.
Back button stuff; I mean, it's not trivial to support it correctly now, and it might just be an increased focus on usability and testing of this sort of thing, but hitting back was always dicey -- half the time you'd get some error about re-posting form data when you hit back, and if you said no, bad things happened, and if you said yes, worse things happened.
> For forms that use HTTP POST, it may not be safe to retry so the browser asks the user for confirmation first.
this always makes me a bit mad. the user has absolutely no idea what the server is doing... and most users are baffled by this message and can't understand why they would want to do anything else other than resubmit the form, in the vast majority of cases.
if it really is potentially dangerous (it can be) browsers should apologise, not offer the user a gun to shoot his feet with.
Or losing half the fields due to a validation error, which then creates other validation errors when you re-submit. "Oops! Your password contains illegal characters. Please select a new password. (submit) Oops! Please select a state from the dropdown menu."
Internet explorer. A custom CMS. And sometimes some of the posted data is missing... On a single POS. And because data ath end of form is optional, system can't even figure out that something went wrong, it just silently discards it.
Never figured out what problems that particular IE had, but the workaround was simple... I added an extra hidden input field just to check if all was sent. The theory was that at least operator could repost the form if it went wrong - however, it never did again. Thank you IE for your obscure bugs and nonstandard behaviour! Rip. </rant>
Vanilla forms just GET or POST to some server endpoint with all of the <input>s passed in as query parameters. Frameworks (e.g., Rails) put some syntactic sugar on it, but that's really all that's happening. If the form submission contains invalid input, it's customary to return to the form page (with all the values already filled out) and show a server-generated message about what went wrong.
We can now keep the user's state and inform them of errors in a way that is more difficult with server-ride rendering.
reply