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 > "f...@bar.com, ", "f...@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" <bzbar...@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+...@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+...@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 <ann...@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. `._.-(,_..'--(,_..'`-.;.'