This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Anne points out on the whatwg list that if the user inputs "foo@bar.example" and "baz@quuz.example" in a multiple-email input, it seems like authors can't rely on what whitespace will be present -- browsers might return "foo@bar.example, baz@quuz.example" or "foo@bar.example,baz@quuz.example" or even " \t\t\r foo@bar.example,baz@quuz.example\f". To simplify processing, the spec should require that there be no whitespace in between the addresses in the list.
For the web page or the server, it sounds really easy to manage this kind of data: splitting on commas then trimming whitespaces for all items will give you an array of emails without trailing or ending whitespaces. If the UA forbid the user to use whitespaces, it would be really annoying (less readable). Or asking to have the value saved internally without whitespaces (for .value) and showing them to the users with whitespaces would make the implementation harder for nothing important.
The UA must already maintain an internal value that's different from what the user has typed in some cases. E.g., "User agents must not allow the user to set the value to a string that is not a valid floating point number." http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state In a typical number-picker, the user can edit the text field, and you want them to be able to type numbers like "-1". But then they have to type "-" first, and that's not valid. So from the time when the user types "-" until they type "1", you have to expose a valid value like "" to JavaScript, but show the invalid value "-" to the user. Also, if the number input has constraints like max or min, it would probably be a good idea to clamp the entered value to match the constraints (pretending the user always input a valid value) instead of complaining and making the user do it. This would also require allowing the user to transiently enter stuff that's not reflected to submission or JS. Also, with e-mail addresses, a good implementation will want to support IDNs. But such an implementation will already have to convert the IDN to punycode for submission and JS access, since the raw IDN is invalid and it can't submit an invalid value (and doesn't want to expose it to JS, since then it would have to expose it as invalid to the author). I don't know why users can't enter invalid values into number inputs but they can in e-mail or url inputs, though. Maybe because a script might want to fix up an invalid e-mail or url somehow, but it's unlikely for number inputs. I definitely feel that it's best to expose the simplest possible interface to authors, even if it's a bit more complicated for implementers. Authors *will* forget to strip whitespace altogether, or will only strip spaces, or will strip whatever their programming language's trim() function does whether or not that matches the HTML5 spec's definition of "space characters". (PHP's trim() strips 0x00 and 0x0B, but not 0x0C. Python's strip() strips 0xB.) Making the implementers do this ensures more consistency on the authoring side at little implementation cost. (Of course authors must be prepared for invalid input anyway. But only in the sense of "it shouldn't cause a vulnerability", not in the sense of "it can't fail randomly and return a cryptic error message". The value in the whole form thing is that authors should be able to rely on them actually working, eventually, except for users who manually alter the submitted values.)
(In reply to comment #2) > Also, with e-mail addresses, a good implementation will want to support IDNs. > But such an implementation will already have to convert the IDN to punycode for > submission and JS access, since the raw IDN is invalid and it can't submit an > invalid value (and doesn't want to expose it to JS, since then it would have to > expose it as invalid to the author). Q: if we consider IDNs here anyway, why not make them valid in the first place?
We don't want to expose IDNs in submitted values or to script, because a lot of e-mail-related stuff doesn't know about them and might break if it hits them. That's the point of punycode, after all, compatibility. IDN-aware stuff can always explicitly convert from punycode to Unicode for display -- and I'd bet a large sum of money that the overwhelming majority of client and server applications are not IDN-aware, and if they work with IDNs it's by accident.
Agreed that the UA representation shouldn't include white space characters. Should be a relatively easy fix. I'll make the author-provided value still allow spaces though.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r5740. Check-in comment: Revamp how type=email multiple='' is specced. http://html5.org/tools/web-apps-tracker?from=5739&to=5740
mass-moved component to LC1