WEBVTT

0
00:00.480 --> 00:01.790
We are not quite done. There

1
00:01.800 --> 00:08.040
is something else that I really need to mention, and that is the valid and invalid pseudo classes.

2
00:08.280 --> 00:13.830
Specifically, this styling controls based on whether their data is valid or not.

3
00:13.860 --> 00:20.220
What's really cool is that form controls with constraint limitations can be targeted based on their

4
00:20.220 --> 00:22.320
valid or invalid states.

5
00:22.320 --> 00:26.880
And when you think or hear the word states, ding, ding, ding 🔔, you got to think of pseudo classes,

6
00:26.880 --> 00:31.950
and the pseudo classes relevant to forms are valid and invalid. In the case of numerical data,

7
00:31.980 --> 00:36.300
by the way, we can also talk about :in-range and :out-of-range data.

8
00:36.390 --> 00:40.170
But anyway, I want to keep it to the :valid and :invalid pseudo classes in this lecture.

9
00:40.200 --> 00:46.290
As I mentioned, form controls with constraint limitations can be targeted based on these two states,

10
00:46.290 --> 00:47.670
valid and invalid.

11
00:47.910 --> 00:53.910
And just remember, I want to be clear, this does not remove the need to perform validation on server

12
00:53.910 --> 00:58.920
side. Even though far fewer invalid form requests are to be expected,

13
00:58.950 --> 01:06.700
invalid ones can still be sent by non-compliant browsers, for instance browsers without HTML5 and without

14
01:06.700 --> 01:11.720
JavaScript or even by bad people trying to trick your web app.

15
01:11.740 --> 01:18.490
So don't think that just adding some simple front end constraints is enough to protect data.

16
01:18.520 --> 01:19.250
It's not.

17
01:19.270 --> 01:22.260
But anyway, what else can I say about the valid and invalid?

18
01:22.270 --> 01:25.090
Well, firstly, controls with no constraint

19
01:25.090 --> 01:28.440
validation will always be valid.

20
01:28.450 --> 01:33.820
So if you go and target that class and you don't have any constraint validation, then the styling will

21
01:33.820 --> 01:37.600
always apply to that widget because it will always be valid.

22
01:37.630 --> 01:38.170
Make sense.

23
01:38.170 --> 01:39.010
Makes sense.

24
01:39.040 --> 01:47.140
Next, controls with the required attributes set on them and that have no value are counted as invalid.

25
01:47.170 --> 01:52.210
In other words, they will be matched with the invalid and the required pseudo class.

26
01:52.570 --> 01:56.690
And what about some of the form controls that have patterns associated with them?

27
01:56.710 --> 02:00.490
Things like input where its type attribute is set to email.

28
02:00.580 --> 02:03.400
Or, what about where type is URL?

29
02:03.430 --> 02:09.610
Well, in those instances the controls with built in validation are invalid when the data entered into

30
02:09.610 --> 02:17.710
them does not match the pattern specified. And finally controls whose current value is outside the range

31
02:17.710 --> 02:23.440
limit specified by min and max attributes, are invalid, but they're also going to be matched by out

32
02:23.440 --> 02:24.460
of range.

33
02:24.580 --> 02:25.420
What?

34
02:25.450 --> 02:27.250
What is this out of range?

35
02:27.250 --> 02:28.060
What is that all about?

36
02:28.090 --> 02:28.570
Don't worry.

37
02:28.570 --> 02:30.370
We're going to be talking about that shortly.

38
02:30.400 --> 02:34.300
For now, I want to stop here and I want to go back to our cool signup form.

39
02:34.300 --> 02:39.580
And I want us to now target the :valid and :invalid pseudo classes in order to improve upon it.

40
02:39.610 --> 02:40.330
I can't wait.

41
02:40.330 --> 02:41.080
I'll see you now.