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:
- "Premature Inline Validation", and
- "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)
developer.mozilla.org/en-US/docs/L...
HTML5 provides the very barest of validation, scripts are still required for anything industrial-strength.
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.
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.
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.
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.
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.