This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
- 'valid e-mail address' rule doesn't support EAI [1]. [2] - We need to avoid punycode conversion in order to support EAI. The current <input type=email> assumes its value is always US-ASCII. Proposal: A) Allow EAI in type=email by default, and input.value returns user-input string as is B) Add new boolean attribute to enable EAI. e.g. <input type=email internationalized> C) Add new input type for EAI. e.g. <input type="email-i18n"> This was requested from a non-Chrome Google team. [1] http://datatracker.ietf.org/wg/eai/ [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address
The plan is to do B or C at some point once there's a critical mass of authors who actually support non-ASCII e-mail addresses on the back end (at the time we added type=email, non-ASCII e-mail addresses on the back end were basically unheard of).
(In reply to Ian 'Hixie' Hickson from comment #1) > The plan is to do B or C at some point once there's a critical mass of > authors who actually support non-ASCII e-mail addresses on the back end (at > the time we added type=email, non-ASCII e-mail addresses on the back end > were basically unheard of). A Google team is developing a backend, and facing this issue in the frontend now.
I recommend just using type=text for now, with custom validation code. Until there's a critical mass of sites that are ready for this, I'm worried that adding it will just cause authors to use it (because "it's the best practice") and then have server-side problems when they get non-ASCII addresses they can't handle, and we'll end up having to scuttle it and try again with a new type name, or otherwise get generally confused.
*** This bug has been marked as a duplicate of bug 15489 ***