[whatwg] Make "foo@bar.com, " a valid email address list

This thread led me to realise there were a number of problems in the spec 
with the multiple="" attribute as applied to type=email, including a poor 
definition of how list="" applies, a poor definition of how selectedOption 
applies, an incoherent expectation that the selection API should apply to 
type=email at all (which doesn't work since the UI is supposed to be 
IDN-based but the output and the API isn't), and various complication 
regarding how values are to be checked, depite the recent fixes in that 
area. I revamped how it was specced and hopefully it makes more sense now.

On Thu, 21 Oct 2010, Mounir Lamouri wrote:
> 
> For the moment, a valid email address list is a set of comma-separated 
> tokens where each tokens are a valid email address so in the case of 
> "foo at bar.com, ", "foo at bar.com" is a valid email address but not "".
> 
> Unfortunately, as soon as you want to put a UI on top of that, values 
> will always be appended by ", ".

I've changed the spec so that it decouples the underlying DOM and 
submission value from the UI, so that's no longer an issue.


> You can found an example of that kind of UI in GMail.

The GMail To:/Cc: controls are rather different than the type=email and 
type=email/multiple controls. For example, their output value includes 
names, not just e-mail addresses. If we want to support that use case, 
that's likely an entirely different control, not type=email. For example, 
we'd want to add an API to hook into the autocompletion, we'd want an 
expectation of a multiline UI, we'd probably want individual values to be 
manipulatable using drag-and-drop, etc. I think that's something we should 
probably not try to address at this stage, where we're still trying to get 
basics like date controls sorted out.


On Thu, 21 Oct 2010, Mounir Lamouri wrote:
>
> Oh, and I forgot to add that we need to fix that to have @list working 
> nicely with <input type='email' multiple>.

list="" as previously defined didn't make any sense for type=email/ 
multiple; I've fixed it to operate on the individual values and not on the 
whole string.


On Fri, 22 Oct 2010, Anne van Kesteren wrote:
> 
> I do not really get why it being comma-separated is not just the 
> submission format. The UI could be quite different. E.g. on the iPhone 
> email client it is more like an inline list. I think the specification 
> is simply not abstract enough here, as it is for the other controls.

Indeed. Fixed.


> I think it would be better to simply omit that trailing comma. Which 
> should be allowed. If the specification currently does not allow that 
> (somehow) it would be a bug and is just something that needs 
> clarification.

Indeed. Also fixed.


On Fri, 22 Oct 2010, Rob Crowther wrote:
>
> Is there ever likely to be a DOM API for multiple, eg. offering the 
> value as an array rather than as a string?  If there was going to be 
> then I could see a case for clearing up how trailing commas should be 
> dealt outside of a submission format.

Yes, I expect we'll add a valueAsList feature at some point.


On Fri, 22 Oct 2010, Boris Zbarsky wrote:
> 
> That depends on what meaning of "email address" is used here.  Is:
> 
>   "Zbarsky, Boris" <bzbarsky at mit.edu>
> 
> a valid "email address"?

Not for this control, no.


On Fri, 22 Oct 2010, Aryeh Gregor wrote:
> 
> Gmail also allows addresses like "Aryeh Gregor 
> <Simetrical+w3c at gmail.com>", which are not valid e-mail addresses per 
> spec.  Good UI here would be to accept an address like that but strip 
> the part outside of the <> for the purpose of submission and script 
> access.

That's certainly an allowable UI (now). I don't think it oblivates the 
need for a control that lets authors provide e-mail addresses with names 
that the server then receives, but that's another story, as discussed 
above.


On Sat, 23 Oct 2010, Aryeh Gregor wrote:
> 
> Good point.  What are the use-cases for accepting a list of bare e-mail 
> addresses like "Simetrical+w3c at gmail.com" (without the angle brackets)?  
> The obvious use-case for a single such address is when you're supplying 
> your address to a site, since existing applications normally don't want 
> anything but the address itself.  For multiple, maybe a list of 
> usernames, on a site where usernames are e-mail addresses?  It seems a 
> bit of a stretch.

The single e-mail use case is indeed what you describe. The multiple 
e-mail use case wasn't very well thought through, I think. I don't think 
it makes sense to have type=email and type=email/multiple have different 
concepts of "email", though. If there aren't good use cases for the 
multiple e-mail address case, I think we're better off dropping support 
for multiple="" from this type, and revisiting it in the future.


> On Fri, Oct 22, 2010 at 7:13 PM, Anne van Kesteren <annevk at opera.com> wrote:
> > Sure, I would expect the way it is serialized for submission and for 
> > .value to be the same. I would not expect any whitespace there either. 
> > The way it is currently defined does not make much sense to me and 
> > seems to assume a particular UI.
> 
> I filed a bug:
> 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11137

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 5 January 2011 15:40:38 UTC