Why does Input Type Email validation accept pointless domains?

Question

The input type[email] is intended to validate whether the field is being filled with a valid email.

But several times I have gone through questioning in some projects about why this field accept some types of email that are apparently invalid.

Example:

[type=email]:invalid{
   color:red;
}
[type=email]:valid{
   color: green;
   border-color: lightgreen;
}

<input type="email" value="wallace@dominio-sem-ponto-com" />

<input type="email" value="wallace@xx" />

<input type="email" value="[email protected]" />

<input type="email" value="wallace" />

If you notice, none of the emails whose domain was without the ".com" or ".net" was marked as invalid.

Why does this happen?

Why the e-mail address "wallace@dominio-sem-ponto-com" was considered valid by browser?

Is there any case where it would be valid to use a domain without the value after the point (.com, .net, etc.) ?

Answer 1

validation occurs only on account of @, domain is actually a name, ex: tassio@dominio, not necessarily need to be a sub domain (with dot), eg: [email protected], In what situations can this occur? Within an intranet for example, or if the.br registry or other registry agency releases the primary domain registration there for example could register a domain "google", to access the site would use only http://google and an example email would be contato@google.

Answer 2

According to the W3C:

The <input type="email"> is used for input Fields that should contain an e-mail address.

Depending on browser support, the e-mail address can be Automatically Validated when submitted.

Some smartphones recognize the email type, and adds ". com" to the Keyboard to match email input.

That is, this field is used input fields that must contain an email address and depending on the browser support, the email address can be automatically validated when sent.

Some smartphones recognize the type of email and add ". com" to the keyboard to match the email entry.

Why the e-mail address "wallace@dominio-sem-ponto-com" was considered valid by browser?

Because in the validation of e-mail using the input type="email", the value must start with a letter or a number, followed by the symbol @, then end with a domain name.

If you want to create your own validation rule, just use the attribute pattern, It allows us to define our own rule to validate the input value using Regular Expressions (Regex). If the value does not match the specified pattern, the input will throw an error.

If you want the form to only accept [email protected], you can use it as follows:

<input type="email" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}$" />

Curiosity: In this site you can test the validations input.

Answer 3

This is because the input of type="email" accepts any text typed within you with the sole condition of owning [email]@[domínio] in its value. To circumvent this and have a better validation on the side of the user client of the site, it is recommended to use the attribute pattern='' that sets a pattern for the value of that input be accepted, but be careful, on the client side, it can make changes by the console to validate the form, so it is always recommended to do a validation on the server side as well.

Something useful to look for is the validation of forms with RegEx, which are the regular expressions passed within the attribute pattern, to facilitate the creation of the above mentioned standards.

A good site to learn RegEx is the http://regexr.com/ .Click on References to see what shapes and expressions are used for validation in html5

Answer 4

In addition:

Is there a case where it would be valid to use a domain without the value after the point (.com, . net, etc) ?

Yes. We should remember that on local hosts (like localhost for example) it would be totally valid to have emails like wallace@localhost. This does not mean that the email is invalid, but rather that it is not a common email "from the internet".

On intranet systems, for example, it may be common to use emails that do not contain conventional domains as we are used to.