On 01/06/2011 12:40 AM, Ian Hickson wrote: > > 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 >> "[email protected], ", "[email protected]" 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.
> On Fri, 22 Oct 2010, Anne van Kesteren wrote: >> 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. I don't see where/how this has been fixed. To me, it's clear that "[email protected], [email protected]" will now be represented as "[email protected],[email protected]" in the DOM but not "[email protected], [email protected]," (which will be "[email protected],[email protected],"). In addition, this value seems to still be invalid. Can you point out the section/line that handle this case? Thanks, -- Mounir
