Validating email addresses with regular expressions can make sense from a UX perspective alongside sending a validation email after the address has been validated as "likely a valid email address".
If for example during a typical registration process the software merely sends an email instead of also trying to validate the address first the user either has to wait until the email has arrived before entering the remaining data or otherwise might end up with invalid registration data that cannot be retrieved anymore. In this case, the user would have to start over again.
This problem could be alleviated by having a two-step process, during which the software merely asks for the email address in the first step and the remaining data can only be filled in after the email address has been verified. However, depending on the requirements of the software it might make sense to not just ask for the email address but additional required information during the first step as well, in which case validating with regular expressions provides a better user experience through feedback.
> Validating email addresses with regular expressions can make sense from a UX perspective
... only to people who are not listening to the complaints from users whose perfectly valid mailboxes are rejected by such systems. It seems somewhat hypocritical for designers to go on about "good user experience" when the user experience in practice turns out to be that it is impossible to give the system their actual electronic mail addresses at all.
It'd be interesting to investigate if there's useful common error patterns that can be detected and then prompt the user to check. E.g. "you entered an e-mail address @gmmail.com. Did you mean @gmail.com?"
Then you could do the hard-fail checks very conservatively and still catch some mistakes early.
One solution would be to be lenient as to what address patterns to accept, e.g. using a regular expression such as /\S+@\S+/ that catches common entry errors but doesn't keep the user from entering uncommon but valid patterns.
The idea here is to help the user avoid mistakes not to actually verify the email address. That's happening at a later stage, i.e. when the user clicks on a confirmation link.
>using a regular expression such as /\S+@\S+/ that catches common entry errors but doesn't keep the user from entering uncommon but valid patterns.
your regex is too strict and doesn't accept all valid email addresses. my."really uncommon".email@is.valid is a valid email address that you would be rejecting.
the sane regex is /.+@.+/. Anything beyond checking for an @ is getting into very complicated territory (even the domain part allows stuff like round and square brackets)
All you're checking is if the user has entered an at symbol. If your regex pattern is going to be that loose then what's the bloody point in even having one? I mean you're ultimately just going to rely on authentication emails anyway.
This expression not only checks for the @ symbol but also makes sure there are no white space symbols (which is a wrong assumption as user wongarsu has pointed out).
Anyway, the point is to assist the user, not to verify the email address actually is valid.
If for example during a typical registration process the software merely sends an email instead of also trying to validate the address first the user either has to wait until the email has arrived before entering the remaining data or otherwise might end up with invalid registration data that cannot be retrieved anymore. In this case, the user would have to start over again.
This problem could be alleviated by having a two-step process, during which the software merely asks for the email address in the first step and the remaining data can only be filled in after the email address has been verified. However, depending on the requirements of the software it might make sense to not just ask for the email address but additional required information during the first step as well, in which case validating with regular expressions provides a better user experience through feedback.