[Bug 11137] Multiple-email inputs should require no space characters between values

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11137

--- Comment #2 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2010-11-02 16:18:39 UTC ---
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.)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 2 November 2010 16:18:44 UTC