Earlier quoted context omitted.
Really the entire idea of client/server-side email "validation" kind of seems like an ancient, cockroach-like anti-pattern that is impossible to stamp out. Like, what is the problem they're even solving? One validates email addresses by sending an email with a token the user then acts on. There are useful things to do with emails, like checking against already registered ones (including any blacklists), but I can't t…
Lots of these kinds of things—at least for companies that aren't just copying others' patterns blindly—are the result of multiple support calls/emails/tickets. The tickets, in this case, would be users complaining about your service being broken when in fact they messed up their email address and don't realize it. There are also some cases in which you want to use the address immediately to reduce friction (as with s…
Re: User Inyerface – A worst-practice UI experiment
#201This has been common for mailing addresses: with a parsing and validation system, the site will tell the user "We think you entered ... as your address; we think your address should be this: ...", along with options to keep the original entry or use the suggestion. This has the advantage of catching mistakes, not making unusual addresses unusual, and letting the user know if the site is interpreting what they entered in a way that won't actually work (eg, leaving off something important, or ordering components badly).