[whatwg] Changing punctuation value of input element in telephone state

[Ian Hickson]

On Wed, 7 Apr 2010, Mounir Lamouri wrote:
> On 04/07/2010 01:08 AM, Ian Hickson wrote:
> > On Wed, 7 Apr 2010, Mounir Lamouri wrote:
> >>>
> >>> Well the alternative is to not have the user agent change the value 
> >>> at all, in which case you still have to do server-side 
> >>> canonicalisation, so I don't think it really makes any difference.
> >>
> >> If the UA is not changing the value, we are sure at least webpage 
> >> authors can easily specify how they want the telephone number to be 
> >> formatted and check it with pattern attribute (or use 
> >> setCustomValidity()).
> > 
> > If the author is doing the formatting, it's really not much better 
> > than a type=text field. The reason to have type=tel is to allow the UA 
> > to do that part of the work.
> 
> As Davis said, there are too many phone numbers format out there so we 
> can't let the UA do a formatting because it will be a bad one in most of 
> the cases. For example, in France, we use 2-digit blocks but in the US 
> people write 3-digit or 4-digit blocks. Maybe the telephone type can be 
> like the search one and be here only for styling ?

What styling would there be?


On Wed, 7 Apr 2010, Mounir Lamouri wrote:
> 
> By the way, it lets me think about something: the telephone state can 
> still be used for autocomplete with phones from contacts.

Wouldn't those numbers of autoformatted anyway?


Note though that the spec doesn't require autoformatting. It's just 
something that I'd expect browsers to do. It's entirely up to the browser 
whether or not it does this, in much the same way as a browser can 
autocorrect spelling in a text field.


On Tue, 6 Apr 2010, Davis Peixoto wrote:
> 
> Tab, this does not means only formatting, but the input length will 
> differ too much.
> 
> Uruguay for example, has only 6 digits number, 8 with international 
> leading code. Brazil has 9 or 10, depending on the region, plus 2 with 
> international leading code.
> 
> That's the point. But as I said, when we have some standard for it (I 
> doubt of this, but let's suppose it), we can put this inside locales 
> configuration. This is a nice idea. Anyway, backend programmer will 
> still need to sanitize this input somehow. Yeah, I do not see much light 
> for this matter.

Note that if users are including the country code, it's just a matter of 
applying the relevant rules, so that's not a big deal. The problem is only 
when the user enters a local number, but then the UA can apply 
locale-specific formatting, just like is done with dates and times.


On Wed, 7 Apr 2010, Kit Grose wrote:
> 
> I'm surprised this was an issue; the Mac OS X Address Book contains a 
> dedicated preferences screen to allow you to define custom formatting 
> rules if they don't automatically behave as you'd like.
> 
> In fact, my suggestion to the entire list was to fall back on the 
> OS-native Address Book's settings for formatting phone numbers, since 
> that is a setting that is certainly going to be the same for a given 
> user between his or her address book and web browser.

Indeed.


On Wed, 7 Apr 2010, Eduard Pascual wrote:
> On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson <ian at hixie.ch> wrote:
> > If there was a true standard, then the spec would refer to that, but 
> > as you say, it's very varied in practice.
> 
> There is quite a standard, even if an implicit one: (almost) no 
> punctuation. Have you ever dialed a "(" or a "-" when phoning someone? 
> In essence, phone numbers are sequences of digits, and punctuation is 
> only used as a convenience to enhance readability.

The punctuation is relevant. For example, in the UK "(0141) 496 0765" would 
be dialed as "496 0765" if you were in Glasgow, but as "0141 496 0765" 
elsewhere. Similarly, "+44 (0)141 496 0765" is never dialed as written; 
from the US you'd dial "011441414960765", from London you'd dial 
"01414960765", and from Glasgow you'd dial "4960765". Without the 
punctuation it's not clear what numbers you'd want to dial -- for example, 
consider the (UK) number "016329600700" -- what would you dial where?


> Maybe I'm being too hasty with this idea but, since machines don't 
> really need the same readability aids as humans do, I'd suggest that the 
> UA simply removes everything other than "+" and alphanumeric characters 
> (and obviously adds nothing) when sending the field. I don't care too 
> much about what they do upon rendering the introduced value (and I think 
> it's probably fine if the browser adds some formatting based on its own 
> or the system's regional settings). The server is only left with 
> replacing letters and "+"; plus any application-specific usage of the 
> value itself (which, by then, will be a string of digits; assumedly 
> representing the sequence of digits to dial).

This is something the server can trivially do itself if it wants. I don't 
see why we'd require UAs to strip possibly punctuation that might help in 
the usage of the number (especially if it's not an international number).

Note that stripping the round brackets from the number above ("+44 (0)141 
496 0765") would result in an invalid number. You never dial both the "44" 
and the "0".


> Other than that, the only safe alternative would be to leave the values 
> untouched, so the page can say what it wants, the user honor it, and the 
> server get it as expected; or gracefully degrade to an error message 
> that actually points to the user error (rather than an error introduced 
> by an UA trying to be out-smart the user).
> 
> For sites that are ready to sanitize values from a specific locale; but 
> which are accessed through an UA with different settings (ie: on a 
> public place while abroad), the UA adding locale-specific stuff to a 
> phone value is very likely to render whole forms unusables.

Adding, yes. Changing the spacing seems harmless.

Nothing in the spec suggests browsers should add or remove numbers or 
letters. The spec just says browsers can change the punctuation. I've 
tried to make this clearer.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'