I've added <input type="tel">. It's more or less like type=text or type=search, but optimised for phone numbers.
I only added this based on the comments from implementors saying they'll implement this (indeed saying they might implement it even if it's not in the spec). As with any feture, it will be removed if it is not widely implemented. Here is some of the feedback that was sent on this issue: On Tue, 31 Mar 2009, Antti Koivisto wrote: > On 31.3.2009, at 0:12, Ian Hickson wrote: > > On Mon, 30 Mar 2009, Antti Koivisto wrote: > > > > > > I'd like to propose a new <input> type attribute value for phone > > > numbers (<input type="phonenumber"> perhaps). The primary benefit > > > would be to enable use of phone number specific input methods (for > > > example a virtual keyboard) and pickers (for example a system > > > address book). A useful minimal implementation could limit the > > > allowed characters to those legal in phone numbers (+ * # and 0-9). > > > > Would the pattern="" attribute not be enough? > > Pattern attribute does not communicate the type. It would not allow you > to bring up phone book based pickers or special input methods so it does > not satisfy the use case. It also pushes the burden of specifying a > right pattern to authors, something they are likely to get often wrong. > > > Generally speaking at this point it's probably best for us to wait for > > the currently defined features to be more widely implemented before we > > add any more controls, since otherwise we'll just end up with > > different browsers implementing different subsets and it'll be a big > > mess. > > While I agree with the general sentiment I think there is some > surprising asymmetry in including email type but leaving this > unspecified. > > Different browsers implementing different subsets is probably > unavoidable initially in any case. On Tue, 31 Mar 2009, Boris Zbarsky wrote: > > A brief look around shows the following characters also commonly used in > phone numbers as people actually type them in the US: ' ' (ascii space), > '.', '-', 'x' (this last in cases like "1-800-123-4567 x235"). > > This last case in particular is one I would suspect involves a good bit > of regional variability; I doubt the Latin lowercase 'x' is used > throughout the world to denote extensions. On Tue, 31 Mar 2009, Markus Ernst wrote: > > There are more issues like this - vanity numbers with letters a-zA-Z > seem to be popular in the USA, while they are marginal here in the > German speaking countries. Also, the separation of phone numbers into > blocks and the block separation character(s) are subject to regional > differencies, and several formats might be considered as valid in the > same region. > > Here in Switzerland, these formats are quite common: > +41 (0)12 345 67 89 > +41 12 345 67 89 > 012 345 67 89 > 012 345 6 345 > > In private use you find more variants, e.g.: > 012-345'67'89 > 012/345'67'89 > 012 345/67/89 > > You will find other formats in other countries. I have no idea what > people type in Japan or Sri Lanka. > > So, while e-mail addresses have a strictly defined format, this does not > apply to phone numbers. Internationalisation would be necessary to > validate them, and still it would be a hard task, as complete sets of > valid formats might not be available for every country. On Tue, 31 Mar 2009, Kristof Zelechovski wrote: > > Phone numbers do have a strictly defined format, and the definition is > provided by ITU-T E.123. On Tue, 31 Mar 2009, James Graham wrote: > > FWIW I would imagine that the most useful aspect of <input type="tel"> > or whatever would not be validation (because validation is hard) but > would be better integration on mobile devices e.g. making the default > action of the keypad be number keys, making phone numbers from the > contacts list available, etc. (these were both pointed out already). > Therefore whilst I totally recommend this feature be postponed for > HTML6, I think it makes a lot of sense and that problems with validation > are a red herring. On Tue, 31 Mar 2009, Maciej Stachowiak wrote: > > Not just on mobile devices. Desktop browsers can also offer integration > with the system Address Book, and to some extent do this already based > on heuristics that guess which input fields are for phone numbers. I > believe every major browser has heuristics like this. Having an > unambiguous way to indicate that a field expects a phone number would > allow for better integration. It would eliminate false negatives, since > phone number fields may be missed if they don't use a name="" that > enables the browser to guess. And by eliminating false positives, it > would make it practical to make more extensive changes to the field, > such as actually replacing it with a pop-up to choose phone numbers for > example. > > While I sympathize with the desire to see current HTML5 form controls > implemented first, frankly, we would be more interested in implementing > <input type="tel"> than the six different date/time controls currently > in HTML5. It seems to me that entering a phone number is much more > common than entering any kind of date at all, and certainly more common > than entering a month or a week. [snip other feedback] -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
