W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

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

From: Martin Atkins <mart@degeneration.co.uk>
Date: Thu, 13 May 2010 11:31:58 -0700
Message-ID: <4BEC459E.2000003@degeneration.co.uk>
On 04/07/2010 03:49 AM, Mikko Rantalainen wrote:
>
> And nowadays you will see stuff like this:
> +358 (012) 1234 567
> This contains the area code for Finland "+358" in addition to the
> Finnish "local distance number".
> However, there's a catch! When dialing, you must press +358121234567
> because the first zero of area code is dropped if there's a country
> code. As a result, it's not safe to blindly drop the parenthesis from
> user inputted phone number.
>

This is the case in the UK too.

While in the US phone users tend to realise that the "1" on the front of 
the number is the national dialling prefix, in the UK the "0" that 
signals national dialling is always quoted as part of the dialling code, 
and phone users who don't use international numbers frequently don't 
realize that it's not strictly part of the telephone number.

A common notation for UK numbers with an international prefix is:
     +44 (0)1206 123456

...which, just as in your Finnish example, is either dialled as 
+441206123456 or as 01206123456 (were + stands in for your country's 
international dialling prefix.). Dialling +4401206123456 doesn't work.

So with all that said, I don't think dropping punctuation is an adequate 
solution. Cellphones I've had both the US and the UK seem to be able to 
recognize the local conventions and normalize them to the correct form 
for number recognition, so perhaps browsers could adopt the same 
appraoch but this assumes that they would be able to detect what 
geographical area they are being used in and have support for various 
international numbering schemes, which seems like a big burden to put on 
a browser when dealing with telephone numbers is not its core concern.
Received on Thursday, 13 May 2010 11:31:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC