- From: <bugzilla@jessica.w3.org>
- Date: Thu, 09 Feb 2012 09:50:11 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489 --- Comment #13 from Mathias Bynens <mathias@qiwi.be> 2012-02-09 09:50:09 UTC --- > The markup is invalid, regardless of what the user does. Note to self: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#e-mail-state-(type=email) (this was new to me) > > Let’s say Page A has the following markup. After submission the input is > > inserted into a database. > > > > <input type=text name=email> > > <!-- or even a typo, which makes it fall back to type=text… --> > > <input type=e-mail name=email> > > Then, if the user enters an IDN address, and the server doesn't validate its > input (!), the server will be in a state where if it tries to send mail, it > will fail. This assumes that the mail server / client can’t handle IDN email addresses. > > Page B uses type=email, and reads the value from the database: > > > > <input type=email value=foo@mañana.com> > > This means the server is non-conforming, as it outputs invalid HTML. This bug is about making it conforming. > > Alternatively, the un-Punycoded email address may already be stored in the > > database for a variety of reasons. > > Like what? You could have imported a database (say, contact details of all your clients) from a desktop app that allowed IDN emails. This restriction in the spec forces web developers to implement their own Punycode encoder on the back-end, even though browsers already have one built-in. By lifting this restriction, authors would only need to validate the email addresses on input in the back-end (as is the case anyway). -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 9 February 2012 09:50:16 UTC