- From: Mounir Lamouri <mounir.lamouri@gmail.com>
- Date: Thu, 06 Jan 2011 14:18:09 +0100
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 >> "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. > 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 "foo at bar.com, bar at bar.com" will now be represented as "foo at bar.com,bar at bar.com" in the DOM but not "foo at bar.com, bar at bar.com," (which will be "foo at bar.com,bar at bar.com,"). In addition, this value seems to still be invalid. Can you point out the section/line that handle this case? Thanks, -- Mounir
Received on Thursday, 6 January 2011 05:18:09 UTC