Sunday 20 June 2010 — This is more than 14 years old. Be careful.
In a comment on my last post, drozzy wrote:
PS: Whenever I try to post a comment on your blog, my email always gets @ and . replaced by (at) and (dot) symbols, so that I have to retype it before clicking on “add it” button. This is a bug methinks. Fyi I am using chrome.
I tried it, and sure enough, Chrome would not let a comment be submitted.
Somewhere in the reptilian brain of my comment code, I was cloaking email addresses by changing “.” to “(dot)” and “@” to “(at)”. This meant that when previewing a comment, the valid email that you had entered now is not a valid email address.
This is fine, except in Chrome. A couple of months ago, I changed the comment form’s field to use an HTML5 type=”email” field. I figured it wouldn’t hurt anything, and would give iPhone users a nicer email-specific keyboard to use.
But it turns out Chrome is being even more “helpful”: it won’t let a form submit if an email field has an invalid email address in it. And “ned(at)nedbatchelder(dot)com” is not a valid email address, no matter how obvious it is to us humans what is meant.
I couldn’t remember why I wanted to cloak email addresses like that in the first place, since they aren’t displayed on the site anyway, and even if they were, it should be output like that, not input like that. So I removed the cloaking, and Chrome is working again.
Playing with Chrome a bit, it seems that they’re using the same ultra-liberal validation I recommended in Humane email validation: stuff, at, stuff, dot, stuff, where stuff can’t have at-signs or spaces in it, although they don’t trim the string first, so a leading or trailing space will prevent the form submission. I’m a bit surprised that they unilaterally perform this validation, since there’s no UI to let the user know what’s going on: the field is given focus, but there’s no other indication as to why the form didn’t work.
It seems browser incompatibilities are inevitable. This is a big difference between the way the browsers work. And one of the key theories of HTML5 email fields is that they don’t break anything, just make it nicer. Mark Pilgrim closes his exhortation on HTML5 email fields with:
To sum up: there’s no downside to converting all your email address form fields to type=”email” immediately. Virtually no one will even notice, except iPhone users, who probably won’t notice either. But the ones who do notice will smile quietly and thank you for making their web experience just a little easier.
Seems to me like someone noticed...
One more thing: I considered digging into the Chromium source to find the validation to see what the real rule was, and whether it could be disabled or controlled in some way, but the Chrome project uses all custom tools, and even just pulling the source from svn indicates the use of gclient, whatever that is. Too much trouble.
Comments
static const char emailPattern[] =
"[a-z0-9!#$%&'*+/=?^_`{|}~.-]+" // local part
"@"
"[a-z0-9-]+(\\.[a-z0-9-]+)+"; // domain part
One way to search and browse the source is using www.google.com/codesearch with package set to "(src.chromium.org)|(svn.webkit.org)".
Here's a search that zeroes in on code relevant to input fields with type=email: http://www.google.com/codesearch/advanced_code_search?hl=en&q=EMAIL+file:WebCore+lang:c%2B%2B+package:(src.chromium.org)|(svn.webkit.org)
That said, the code for ValidityState.cpp seems to have moved on quite a bit since it looked like the snippet Mounir posted above. I honestly cannot work out where the email validation pattern is in the latest source. Perhaps the over-zealous validation has been removed already.
And yes, I had to start Firefox just to submit this comment :)
Add a comment: