But when it comes to validation, it is not complete.
And by complete, I mean it's not good for a security and logic.
We already know that server side code is required to make sure your site is secure.
You don't want hackers coming in and writing malicious code into your input fields and submitting that
onto a server.
Okay, so that's security.
But the logic itself is also not complete when we use the email type.
And what do I mean when I say the logic is not complete?
Well, x@y will be a valid email address according to the default provided constraints.
And this is because the email input type allows intranet email addresses by default.
And please note my dear students, it's actually not possible to verify if the address provided is in
existence.
You cannot do this on frontend.
This is actually an issue that you have to handle by your server side scripts.
A good way to test for a valid email address is to send a link to that email and that when the user
clicks it, confirms that the email is valid.
We've all seen this in action with many sites that you and I sign up to. So just bear that in mind,
that using this type of email won't ensure that it is actually a valid email address.
This is not to say we can't do anything on the front side.
We've already seen the use of the pattern attribute in other areas of code in this course, and this allows
us to of course implement different validation behavior on our emails.
And of course we can also use the title attribute to display custom error messages.
Let me show you this in action.
As I mentioned, what we can do, is we can improve ourselves validation rules.
One way we can improve frontend validation is to use the pattern attribute.
And we did get into the pattern attributes when we were talking about passwords.
So I don't want to get into it here again, but I'll just show you a very, very quick example.
So, say we have a site and you require, for whatever reasons, the user to have a Gmail account.
So instead of saying enter your email, let's say "Enter your valid gmail account email".
So it has to be Gmail.
How can we implement this?
Well, we know that Gmail is just text, and we know that the pattern attribute is a regular expression
allowing us to define rules and check patterns within text.
So this will be a very easy rule to define with the pattern attribute.
So let's include the pattern
attribute. And regular expressions aren't only applicable with JavaScript, but when it comes to HTML, the
regular expression it expects is in JavaScript syntax.
So what we do is we wrap it in a string.
We can have any characters, right?
But at some point we are going to have to have the @ symbol, and the "gmail.com". And that is it.
That's our pattern.
We can also put on the required attribute, making this a required field before a user can submit the
form.
And of course we can provide a custom error message to the user by using the title attribute.
So here we can say "Please provide a valid Gmail
email address".
Let's go back now to the browser.
Let's expand the browser.
And let's go abc
@abc.
We click submit, and now we are prevented.
How cool.
Please match the requested format and there is our title,
right?
Our title attribute:
"Please provide a valid gmail email address".
So of course if the user goes back and writes @gmail.com and clicks submit,
this will work.
So there we go.
That's just a very, very rudimentary, very high level example of us using the patent attribute to
enhance and improve our client side validation.
Ooh, this is fun, isn't it?
So just remember, that patent attribute is used to specify a regular expression that the input elements
value is checked against. And this patent attribute does work well with an input of type email.
We've actually used it in previous lectures.
I think it was with the password type, remember that?
So here, we've seen another example of using the pattern, but this time on email.
And just to refresh your memory, a regular expression is nothing more than a sequence of characters
that forms a search pattern, right?
So don't get overwhelmed.
But moving on, let me just summarize what we've learned with this type of email.
Firstly, the email type makes web development easier.
Why does it make it easier?
Well, because validation work is done automatically by the browser.
If the required attribute has been specified as well, the browser will not even accept the form to
be submitted until the user types in an email.
It just means we have to write less JavaScript business logic ourselves.
And secondly, you can choose to style the email input type.
Of course you want to do this because you want all your styles to appear standard across the board and
it's very easy to apply CSS styling to an email.
All you got to do is target your input with type email and of course apply your own CSS styles.
Very intuitive.
And finally, another benefit of using type email is that touch devices will show the appropriate keyboard.
For example, when the type is set to email, you're going to be seeing the @ symbol and the period
symbols easily, and it just helps you fill in the fields.
So there you go
my dear students, we've looked at the input of type email. We've looked at the benefits it brings.
We've looked at examples.
I hope it's starting to become more intuitive.
See you in the next lecture.