DEV Community

George Jempty
George Jempty

Posted on • Updated on

Form Validation: You're (likely) doing it wrong

First of all, run, don't walk, and read the following about "Usability Testing of Inline Form Validation", it goes into far more general detail, though I may follow up with a post about a morsel they don't cover. The two main categories of issues the article is concerned with are:

  1. "Premature Inline Validation", and
  2. "Outdated Error Messages"

Here I am chiefly concerned with the first pitfall. In fact if you look at some code I wrote, you will see I avoid the second, specifically the line setting the error message (back to) empty: errEl.innerHTML = '';

let fnameEl = document.getElementById('fname');
let lnameEl = document.getElementById('lname');

function confirmEntry() {
    let errEl = document.getElementById('err4-' + this.id);

    if (this.value) {
        errEl.innerHTML = '';
    }
    else {
        errEl.innerHTML = 'The above field is required';
    }
}

fnameEl.focus();

fnameEl.addEventListener('blur', function() {
    confirmEntry.call(this);
});

lnameEl.addEventListener('blur', function() {
    confirmEntry.call(this);
});

Unfortunately though, as written, the above will correctly display an error if the first field is tabbed through, but then if trying to shift-tab back to correct that error, it will annoyingly display an error for the second field. This sort of thing is covered in the above-referenced article.

A solution seems to be to add some "state", the following is quick and dirty and probably not perfect, but should be less annoying for users:

let lastError;  

function confirmEntry() {
    let errEl = document.getElementById('err4-' + this.id);

    if (this.value) {
        errEl.innerHTML = '';
        lastError = '';
    }
    else if (lastError) {
        lastError.focus();
    }
    else {
        lastError = this;
        errEl.innerHTML = 'The above field is required';
    }
}

I've created a Gist containing the above code, both revisions being available here. And here is the follow-up post mentioned above.

Top comments (7)

Collapse
 
bgadrian profile image
Adrian B.G.

"One of the features of HTML5 is the ability to validate most user data without relying on scripts. "

developer.mozilla.org/en-US/docs/L...

Collapse
 
dexygen profile image
George Jempty

HTML5 provides the very barest of validation, scripts are still required for anything industrial-strength.

Collapse
 
bgadrian profile image
Adrian B.G.

True, but is a start, a foundation which you build, and is often missing from articles about form validation.
I just want to remind the readers that they should start with HTML5 APIs and CSS3 then build on top of them.

Thread Thread
 
dexygen profile image
George Jempty • Edited

HTML5 validation is not going to help whatsoever -- not even as a foundation -- with a) the sorts of validation referred to in the article linked to at the top of my post, or b) in my example i.e. avoiding error messages when shift-tabbing to correct a previous error. HTML5 validation doesn't providing anything "holistic" like that; that's why mention of it is missing from my post.

Thread Thread
 
worc profile image
worc • Edited

it does seem like you're missing the use of html5 validation here. it can provide the basic is this valid value to higher-level concerns like should we display an error yet. the code examples here are pretty rough/imperative around the edges without it.

Thread Thread
 
dexygen profile image
George Jempty • Edited

The point of my examples are to quickly (without regard for it not being declarative, which I know a thing or two about, see: dev.to/dexygen/accidentally-declar...) emulate what's going on in the article linked to at the very top -- please read it if you haven't. And using HTML5 validation is like crossing a river on a bridge that doesn't even go half way across. Building the rest of the bridge to link up is not ideal, just better to build an entire bridge to your exact specifications to begin with.

Thread Thread
 
worc profile image
worc

i guess i would take a different analogy and say that html5 validation is more like sinking pylons into the river bed / bedrock so that you can run a more fully-featured roadway across the river.