<div class="gmail_quote">Thanks very much for this analysis!</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Sun, Aug 23, 2009 at 12:41 PM, Aryeh Gregor <span dir="ltr"><<a href="mailto:Simetrical%2Bw3c@gmail.com">Simetrical+w3c@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Inspection showed that the overwhelming majority of the failures were<br>
due to the presence of excess whitespace, often a single trailing<br>
space, or a space inserted before or after the @ sign.  When I<br>
adjusted the regex to ignore those failures, I got a smaller list, 202<br>
(about 0.007% of the total):</blockquote><div><br></div><div>I think telling user agents to strip leading and trailing whitespace is a good idea.  I'm not as sure about stripping whitespace in the middle.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Some of these were clearly wrong, and shouldn't have been confirmed to<br>
begin with.  Some even didn't have an @ sign, so probably were<br>
submitted in some window when we did no validation at all (and I have<br>
no idea how they got confirmed).  Of the ones that possibly work,</blockquote><div><br></div><div>You said there were 202 rows total in this group.  How many of those 202 are "ones that possibly work"?</div><div>
<br></div><div>I ask because if it is significantly less than 202, then the failure rate (if we strip whitespace) is noticeably less than 0.007% of your sample.  I am not as firmly on the side of "never reject anything conceivably valid", probably because I think there's more of a chance of type=email obsoleting silly JS-based validators if we do it right.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So why not have the spec say that in the case of e-mail addresses, the</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

browser may warn the user, but should permit them to submit the<br>
address anyway?  If the user is willing to override the warning, then<br>
it's likely that they personally know that the e-mail address works,<br>
e.g., because they use it.</blockquote><div><br></div><div>I don't think this is a very valuable option because I don't think a UA can make good UX out of it (I speak as a member of the Chromium team who works on UX).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Alternatively, you could just loosen the restrictions even further,<br>
and only ban input that doesn't contain an @ sign.  (Or that doesn't<br>
match ^[^@]+@[^@]+\.[^@]+$, or whatever.)</blockquote><div><br></div><div>One notable datum missing from your otherwise useful analysis is how many _invalid_ email addresses not allowed by the current definition would be allowed by this.  I suspect the number is large.  I would be willing to trade a tiny number (<0.007%?) of false negatives to avoid a large number of false positives, especially since I suspect that if the check were weakened this far authors would be more likely to continue with their (currently lousy) hand-written validators.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Or just don't ban anything<br>
at all, like with type=tel.</blockquote><div><br></div><div>I don't support this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I think this input type has only been implemented in Opera so far.</blockquote>
<div><br></div><div>I am mentoring a student who is writing a patch for this in WebKit as we speak -- we were just discussing the implementation yesterday and I believe he hopes to have it out for review tomorrow.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I don't think there are serious interoperability concerns<br>
with changing it at this point,</blockquote><div><br></div><div>I agree, it would be fairly easy to switch if the validation algorithm were changed.</div><div><br></div><div>PK </div></div>