[1] http://referencesource.microsoft.com/#System.ComponentModel....
I would hate to be the programmer who had to debug that regex.
Behold: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
Well, as far as authority/canon goes, it's typically dictated by the IETF and not W3. And, sure, they could cooperate with one another but, really -- if there's an authority on the protocols that describe email (SMTP, POP, IMAP, etc) -- it shouldn't be the World Wide Web Consortium.
That said, the IETF does tend to draft RFCs that reflect actual implementations (at least their intended design), but since they often bias towards interoperability, it's unlikely they'd narrow the scope of the email address grammar.
Ditto for internationalized TLDs like something@taiwan.台灣).
I'm not sure if this is really that bad, but I don't like it.
Otherwise you're just asking for trouble when the same user who signed up with an email address at maré-design.fr later tries to reset their password with an email address at xn--mar-design-d7a.fr. Sorry, you don't seem to have an account with us.
The same thing happens with URLs. Some browsers send the Host: header in punycode but send the referer in UTF-8. Who knows how they encode CORS headers and all the other newfangled stuff that contains bits and pieces of URLs. You have to consistently convert one to the other before using any of them.
IDNs are a mess.
I don't think <input type="email"> does that though. Maybe it should, but users might be surprised to see their address automatically turn into some ugly unreadable xn--whatver-d7a domain. After form submission then yes of course any sane process will convert them to a canonical form.
I know there were good reasons to use punycode instead of UTF8 for IDNs, but it sure is a mess.
Email addresses do not need escape sequences.
That way if you don't mind letting through double periods or domain segments having more than 63 characters, you can validate an email with two character classes separated by an @. The basic regex looks like [xx]+@[yy]+
You know that's exactly what "valid" means, when talking about something standardized, right?
In HTML there's no reason to use " outside of an attribute value. Should browsers reject it?
Also W3C produced HTML specs are hardly gospel about email-related things (but I don't know whether there's anything wrong in this case).
Edit: There is also a version by WHATWG[2] here:
It apparently does a more thorough validation than the W3C one in the domain part, but the difference between the two is not apparent in practice.[1]: http://www.w3.org/TR/html-markup/input.email.html [2]: https://html.spec.whatwg.org/multipage/forms.html#e-mail-sta...