Lesson Description
The "Form Input Validation" Lesson is part of the full, CSS Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:
Kevin explains how user valid and user invalid CSS states provide real-time feedback in form inputs. He demonstrates showing success and error states based on user interaction and how to target specific inputs for better validation styling.
Transcript from the "Form Input Validation" Lesson
[00:00:00]
>> Kevin Powell: Now I also mentioned another thing that would be really nice is as you're going through the fields that we could tell the user if they've got them correct or not, instead of having to wait until we hit submit and then it goes, oh wait, this is a required field. Originally in CSS we've had abilities to sort of do this, but the first ones that we had were input valid. So for that, we could say our outline is 3 pixels, solid, var, color.
[00:00:30]
Oops, color success. And then we could say we have an input invalid is an outline of 3 pixels, solid var color error. You next year see in the success of above. Now something weird's happened. Well, first of all, we're getting it on some of the inputs we don't want it on. But all of these are immediately saying that they're wrong. The reason they're saying they're immediately wrong is because they are all required and they're currently blank.
[00:01:06]
So if it's a required field, the user hasn't put anything in there. That means it is currently invalid. That sort of sucks. This was a pain point for a long time in CSS, but luckily now, they added, they didn't want to change the behavior of this, and this happens a lot in CSS, sort of like with the focus and the focus-visible. They don't change the behavior of the original way the thing was working even though there's a pain point around it, because people have worked around that pain point.
[00:01:35]
And so then if you change the behavior and you go to one of those websites that worked around it, it could break the new way that they've worked around things. So instead of changing the way valid and invalid work, they gave us new properties called user valid and user invalid. These ones are cool. So if I do that, we should see in a second. My CodePen doesn't want to update. Let's just change my HTML.
[00:02:04]
Here we go, we refreshed our form. Now I'm not getting any issues on there. We don't see any success, any error states anywhere. If I come in the field, I write my name, I leave the field, it's now a success because I've interacted with it. Think of user valid and user invalid as the user has interacted with the field, left the field, and now I'm going to check whether or not they got it right. The only caveat to that is if we click in a field, we do nothing, and we leave a field, it doesn't count.
[00:02:37]
Some people are like that should count, the user's interacted with it, but because nothing was typed, it's saying, no, the user, they've gone to the field but they haven't actually interacted with the field, so that doesn't count. If I go in, I do something, I leave, now the user's interacted with it. That's not an email address, it's empty, so we're giving them an error. The browser is sort of smart with these, so let's just do a, you know, email@email.com.
[00:03:11]
That will be considered valid. If I just wrote email, that will be considered invalid. It knows that's not valid because this is the input type of email, so it knows to be expecting an email address. The only thing I'm not sure about, maybe somebody here or somebody in the chat knows this, and I'd love to know cause it's a good thing to know why something like this is considered valid by the browser.
[00:03:40]
Not entirely sure. It's a little bit frustrating. It is a valid email. It's a top level domain, right? So most of those don't allow it, but theoretically, yeah, that's the problem is it theoretically it is, but in practice you generally won't see that, so it's a little bit annoying, but because if you were doing server-side validation, you probably wouldn't allow that. But oh well. Another cool thing with it though, is if I come in my password and I leave, this is invalid, because I didn't put 12 characters.
[00:04:14]
The reason it knows that I need 12 characters is I have a min length on there. So I can say how many characters I want, and as soon as I pass that and I leave, now it's okay. You can get more complex with that one. If you're good with regex, I think my regex here is broken, but you can include a pattern with regex in it, which is at the bottom of this demo. Sort of works, but it doesn't completely, I think.
[00:04:42]
And on any, you, so you could actually use this on your email one as well if you want to check for a dot something, but in here we'll just do it at the start, so we see it. You can have a pattern using regex. And so now I can type 12 characters. It will not consider it valid cause this is also looking for 12 characters, including at least 1 number. Now I add a number at the end, and now it's considered valid.
[00:05:07]
So again, before we get to the server-side validation, we can give them a little bit of information there. It's not giving them all the information they need, it's not telling them why it's wrong, so that could be a little bit frustrating. Probably having a little tooltip underneath would help just saying what you're actually expecting from the user, but sometimes we can't do that. There are ways of like hiding content and only showing it once it's invalid.
[00:05:33]
You can definitely do that if you want to. There's a few accessibility concerns around that as well. Usually errors should, if you're updating content to say there's an error, it helps from an accessibility point of view if it's actually being done with JavaScript. But there's ways of doing it, sort of CSS only that I wouldn't always recommend. So right away, that's kind of cool. Again, we put our name.
[00:06:00]
We put an email. We come in with our password and we're starting to get that feedback that at least we're on the right track as we're going through these. Gets a little bit more complicated down here at the bottom. The reason it gets more complicated down here at the bottom is the required has to be on the input of the radio. And they're all being treated together. So, you know, technically, as soon as one of these is selected, this entire area is becoming valid, and there's no way of saying the stuff inside here is valid, right?
[00:06:40]
We don't have a valid within the same way we have a focus within. It'd be really cool if we did have that, but we don't. There are a few other ways of handling it though. We also have this problem down here, my checkbox, that looks kind of weird that it's getting a green box around it. This is now valid, and the reason it's valid is this is required, so you have to check it to submit. I would suggest doing that.
[00:07:03]
I have to agree to the terms of service. That makes sense that you're requiring people check it, that's, you know they've checked it then before they can actually hit submit, the browser won't let you submit it if not. For this one is an easier fix, then we'll work our way up into this one here. So right now I'm checking all of my inputs, whether they're user valid or user invalid. All I have to do is check only specific ones.
[00:07:38]
So instead of checking everything, I can say an input and then use my attribute selectors like we just saw. Type is equal to text, type is equal to email, type is equal to password, maybe you have other ones that are coming in, the list gets longer and longer and longer, it's a little bit annoying. Definitely works. But one option you do have, instead of saying the ones you want, is you could say the ones we can exclude as well as include things.
[00:08:13]
So we haven't seen this yet with CSS. We're going to come up with a new pseudo class. So we could say any input that is not something. So any input that is not a type equals checkbox can now get it. So my checkbox is not allowed. It's getting the invalid still cause the invalid doesn't have this on it. But these ones do. So any input that is not a type checkbox that is user valid will now get this on it.
[00:08:37]
My radio buttons aren't showing it. They were earlier and I thought they were going to continue showing it, but I would probably also include that here, and within :not you can just put a comma separated list, the same way that we can do a comma separated list of selectors in a regular way, and we can say our type is equal to checkbox, to radio here as well. And you can have as many selectors in there that you want along the way and exclude the ones just to make sure they don't accidentally show up on the wrong thing.
[00:09:10]
So I'm actually going to copy that here, paste that down right there for my user invalid as well, so now it's never showing up on that one.
Learn Straight from the Experts Who Shape the Modern Web
- 250+In-depth Courses
- Industry Leading Experts
- 24Learning Paths
- Live Interactive Workshops