[Bug 12885] Add a new input type=numeric

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

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Simetrical+w3cbug@gmail.com

--- Comment #6 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-06-05 19:26:11 UTC ---
(In reply to comment #0)
> There are other cases when developers need to optimize for numeric input but
> they don't want to require a valid floating point number. A prime example of
> this is input elements for US zip codes which can have leading zeros and some
> non-numeric characters. Other use cases for numeric input which may not
> actually be a real number is a credit card number, passport ID number or
> product sku number.
> 
> Webkit already attempts to solve this problem by displaying a numeric keyboard
> when the developer has set the pattern attribute to "[0-9]*" or "\d*".
> (Reference:
> http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#//apple_ref/doc/uid/TP40009542-CH5-SW1)
> This is a mainstream scenario and developers should have a declarative way to
> indicate that they want a text field optimized for numeric input.

There are several other ways you'd like to optimize soft keyboards, and it
would be nice if authors could do those too.  Useful behaviors might include:

* "numeric": Use numeric keyboard.  Zip codes, credit card numbers, etc.
* "regular": Use letter keyboard, initially capitalized but de-capitalizing
after the first letter.  This is the usual default behavior, suitable for
regular text.
* "uppercase": Use letter keyboard but stay capitalized as the user types,
instead of de-capitalizing after the first letter.  Useful for states, currency
codes, and other abbreviations.
* "capitalized": Start capitalized, decapitalize after the user types the first
letter, recapitalize at the beginning of a new word.  Useful for proper names,
cities, etc.
* "address": Start with numeric keyboard, behave as "capitalized" after the
user hits space.  Useful for street addresses (and probably not much else).

I know that some inputs in native Android apps behave like I describe
"capitalized".  Currently pattern="" can't let you do that, since it's
case-insensitive.  I haven't seen the "uppercase" or "address" behaviors, but
they'd be handy.

I'm not sure adding new types is the right way to go here, though.  Using a
different attribute might make more sense, maybe expect="" or hint="" or
keyboard="".  All the existing types except search really dictate the input's
functionality a lot more than just a soft keyboard hint.  E.g., type=tel could
provide suggestions from the user's address book on a smartphone.

(In reply to comment #1)
> I take it '.', '+' or '-' characters wouldn't be allowed in this new control?

Adrian can correct me if I'm wrong, but it sounds to me like there are supposed
to be no validation requirements.  It's just a hint to switch keyboards.

(In reply to comment #3)
> Another question is, what does the i18n story look like here? Some locales use
> different glyphs than '0' to '9'. Is that just a rendering issue? Or should
> different characters actually be submitted? What is standard practice in these
> locales when entering passport numbers and creditcard numbers?

In my experience, almost all locales use the digits 0-9 for things like credit
card numbers and phone numbers.  But since the proposal is that this is just a
hint for switching keyboards, submission should be the same as type=text, and
the user should be able to enter anything they like.

(In reply to comment #4)
> How does the existing input type=number handle the I18N story for numeric
> digits?  Wouldn't the solution here be the same?

For type=number, the value must be a valid floating-point number at all times,
and the format it's submitted in is (more or less) well-defined.  So the UA can
display the number in whatever format it likes.  In this proposal, it sounds
like the UA is not altering the user's input at all for submission, so that
solution is inapplicable.

(In reply to comment #5)
> It seems to me that type=tel is already what you are asking for:
> http://www.whatwg.org/specs/web-apps/current-work/#telephone-state

That isn't meant to handle things like zip codes, credit card numbers, etc. 
UAs might do confusing things like autocomplete to phone numbers from your
address book.

-- 
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 Sunday, 5 June 2011 19:26:14 UTC