Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Thu, 6 Jan 2011, Mounir Lamouri wrote: > > 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 > "f...@bar.com, b...@bar.com" will now be represented as > "f...@bar.com,b...@bar.com" in the DOM but not "f...@bar.com, b...@bar.com," > (which will be "f...@bar.com,b...@bar.com,"). In addition, this value > seems to still be invalid. > > Can you point out the section/line that handle this case? It was fixed by completely decoupling the /value/ from what the user edits. The user now edits /values/ (plural), and the user agent then "exports" the user's edits to the /value/. (Apologies for the similarity in the names of these concepts; it's difficult to come up with unique yet still understandable names that aren't too verbose.) This is defined in the part of the spec starting with "When the multiple attribute is specified on the element". -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make "f...@bar.com, " a valid email address list
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 >> "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. > 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 "f...@bar.com, b...@bar.com" will now be represented as "f...@bar.com,b...@bar.com" in the DOM but not "f...@bar.com, b...@bar.com," (which will be "f...@bar.com,b...@bar.com,"). In addition, this value seems to still be invalid. Can you point out the section/line that handle this case? Thanks, -- Mounir
Re: [whatwg] Make "f...@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 > "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 . 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" > > a valid "email address"? Not for this control, no. On Fri, 22 Oct 2010, Aryeh Gregor wrote: > > Gmail also allows addresses like "Aryeh Gregor > ", 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 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 as
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On 23/10/2010 22:16, Garrett Smith wrote:
On 10/22/10, Anne van Kesteren wrote:
On Fri, 22 Oct 2010 19:44:42 +0200, Boris Zbarsky wrote:
On 10/22/10 1:25 PM, Garrett Smith wrote:
What is wrong with splitting on comma, e.g.
var validAddressList = inp.value.split(",");
That depends on what meaning of "email address" is used here. Is:
"Zbarsky, Boris"
a valid "email address"?
Not per HTML5.
Link:
http://www.w3.org/TR/2010/WD-html-markup-20101019/input.email.html
Quote:
A single e-mail address.
Any string that matches the following [ABNF] production:
1*( atext / "." ) "@" ldh-str 1*( "." ldh-str )
…where atext is as defined in [RFC 5322], and ldh-str is as
defined in [RFC 1034].
Definition of atext from RFC 5322:
atext = ALPHA / DIGIT /; Printable US-ASCII
"!" / "#" /; characters not including
"$" / "%" /; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
ALPHA and DIGIT are themselves defined in RFC 5234 to be the letters A
to Z (upper-case or lower-case) and the digits 0 to 9 respectively.
Definition of ldh-str from RFC 1034:
::= |
::= | "-"
::= |
::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
::= any one of the ten digits 0 through 9
In other words, the letters A to Z (upper-case or lower-case), the
digits 0 to 9 and the hyphen.
Therefore
"Zbarsky, Boris"
is not a valid email address because the portion before the @ contains
characters that are not atext (namely, the quotation marks, the comma,
the spaces and the left angle bracket) or dots, and the portion after
the @ contains characters that are not ldh-str or dots (namely, the
right angle bracket).
bzbar...@mit.edu is, however, a valid email address.
Alex
--
Alex Bishop
alexbis...@gmail.com
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, Oct 22, 2010 at 5:07 PM, Jonas Sicking wrote: > Actually, pages like gmail needs and uses the whole string "Aryeh > Gregor ", so you don't want to strip it down > to just the email address. I suspect that we'll end up having to > support this format of email addresses too, either as another @type > value, or using some opt-in boolean attribute. 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. On Fri, Oct 22, 2010 at 7:13 PM, Anne van Kesteren 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
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On 10/22/10, Anne van Kesteren wrote:
> On Fri, 22 Oct 2010 19:44:42 +0200, Boris Zbarsky wrote:
>> On 10/22/10 1:25 PM, Garrett Smith wrote:
>>> What is wrong with splitting on comma, e.g.
>>>
>>> var validAddressList = inp.value.split(",");
>>
>> That depends on what meaning of "email address" is used here. Is:
>>
>>"Zbarsky, Boris"
>>
>> a valid "email address"?
>
> Not per HTML5.
>
Link:
http://www.w3.org/TR/2010/WD-html-markup-20101019/input.email.html
Quote:
A single e-mail address.
Any string that matches the following [ABNF] production:
1*( atext / "." ) "@" ldh-str 1*( "." ldh-str )
…where atext is as defined in [RFC 5322], and ldh-str is as
defined in [RFC 1034].
Examples:
foo-bar@example.com
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, 22 Oct 2010 23:07:47 +0200, Jonas Sicking wrote: Actually, pages like gmail needs and uses the whole string "Aryeh Gregor ", so you don't want to strip it down to just the email address. I suspect that we'll end up having to support this format of email addresses too, either as another @type value, or using some opt-in boolean attribute. Yeah, it was supported in the past I think. I forgot why support was dropped. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, 22 Oct 2010 23:09:41 +0200, Jonas Sicking wrote: On Fri, Oct 22, 2010 at 2:57 AM, 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. FWIW, it's not just a submission format, but also a JS format since .value returns a comma-separated list too. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, Oct 22, 2010 at 2:57 AM, Anne van Kesteren wrote: > On Thu, 21 Oct 2010 15:31:04 +0200, 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 "". > > 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. FWIW, it's not just a submission format, but also a JS format since .value returns a comma-separated list too. / Jonas
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, Oct 22, 2010 at 11:31 AM, Aryeh Gregor wrote: > On Thu, Oct 21, 2010 at 9:31 AM, Mounir Lamouri > wrote: >> Hi, >> >> 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 ", ". Indeed, a comma have to be added to >> mark that the user is now editing another email address so the UI can >> suggests new ones. Without adding the comma automatically, the user >> would have to add it by hand to have the UI suggesting new entries. >> So, if we do not fix the specifications, all > multiple> with a UI will be whether invalid or really annoying to implement. >> >> You can found an example of that kind of UI in GMail. > > Gmail also allows addresses like "Aryeh Gregor > ", 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. Likewise, you can just strip the trailing comma for > submission and script access. The entire current spec seems to be > built around the idea that browsers should accept relatively free-form > input but make sure it's only visible to the server or scripts in a > tidied-up form, so that author-written scripts (whether server-side or > client-side) can assume a simple format that's easy to work with. Actually, pages like gmail needs and uses the whole string "Aryeh Gregor ", so you don't want to strip it down to just the email address. I suspect that we'll end up having to support this format of email addresses too, either as another @type value, or using some opt-in boolean attribute. / Jonas
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Thu, Oct 21, 2010 at 9:31 AM, Mounir Lamouri wrote: > Hi, > > 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 ", ". Indeed, a comma have to be added to > mark that the user is now editing another email address so the UI can > suggests new ones. Without adding the comma automatically, the user > would have to add it by hand to have the UI suggesting new entries. > So, if we do not fix the specifications, all multiple> with a UI will be whether invalid or really annoying to implement. > > You can found an example of that kind of UI in GMail. Gmail also allows addresses like "Aryeh Gregor ", 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. Likewise, you can just strip the trailing comma for submission and script access. The entire current spec seems to be built around the idea that browsers should accept relatively free-form input but make sure it's only visible to the server or scripts in a tidied-up form, so that author-written scripts (whether server-side or client-side) can assume a simple format that's easy to work with.
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, 22 Oct 2010 19:44:42 +0200, Boris Zbarsky wrote:
On 10/22/10 1:25 PM, Garrett Smith wrote:
What is wrong with splitting on comma, e.g.
var validAddressList = inp.value.split(",");
That depends on what meaning of "email address" is used here. Is:
"Zbarsky, Boris"
a valid "email address"?
Not per HTML5.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On 10/22/10 1:25 PM, Garrett Smith wrote:
What is wrong with splitting on comma, e.g.
var validAddressList = inp.value.split(",");
That depends on what meaning of "email address" is used here. Is:
"Zbarsky, Boris"
a valid "email address"?
-Boris
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On 10/22/10, Rob Crowther wrote:
> 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.
>>
You're talking about value sent to server, with no js involved. COntrast to:
> 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.
>
What is wrong with splitting on comma, e.g.
var validAddressList = inp.value.split(",");
?
Garrett
Re: [whatwg] Make "f...@bar.com, " a valid email address list
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. 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. Rob
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Thu, 21 Oct 2010 15:31:04 +0200, 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 "". 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. Unfortunately, as soon as you want to put a UI on top of that, values will always be appended by ", ". Indeed, a comma have to be added to mark that the user is now editing another email address so the UI can suggests new ones. Without adding the comma automatically, the user would have to add it by hand to have the UI suggesting new entries. So, if we do not fix the specifications, all multiple> with a UI will be whether invalid or really annoying to implement. You can found an example of that kind of UI in GMail. I think we should change the specifications so an email address list will be valid if it's ending with a comma (plus trailing whitespaces). In other words, if a list of email address have more than one token, the last one can be the empty string. We are thinking of implementing this change in Gecko 2.0 so feedback are very welcome. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On 10/21/2010 03:31 PM, Mounir Lamouri wrote: > Hi, > > 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 ", ". Indeed, a comma have to be added to > mark that the user is now editing another email address so the UI can > suggests new ones. Without adding the comma automatically, the user > would have to add it by hand to have the UI suggesting new entries. > So, if we do not fix the specifications, all multiple> with a UI will be whether invalid or really annoying to implement. Oh, and I forgot to add that we need to fix that to have @list working nicely with . -- Mounir
[whatwg] Make "f...@bar.com, " a valid email address list
Hi, 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 ", ". Indeed, a comma have to be added to mark that the user is now editing another email address so the UI can suggests new ones. Without adding the comma automatically, the user would have to add it by hand to have the UI suggesting new entries. So, if we do not fix the specifications, all with a UI will be whether invalid or really annoying to implement. You can found an example of that kind of UI in GMail. I think we should change the specifications so an email address list will be valid if it's ending with a comma (plus trailing whitespaces). In other words, if a list of email address have more than one token, the last one can be the empty string. We are thinking of implementing this change in Gecko 2.0 so feedback are very welcome. Thanks, -- Mounir
