On Wed, Apr 7, 2010 at 1:31 AM, Ashley Sheridan
<a...@ashleysheridan.co.uk> wrote:
>
> On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
>
> On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson <i...@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.
> There are two exceptions to this: "+" and letters are used as
> replacement for numbers (the plus sign for the international call
> code, the letters for specific digits to enable creating "branded"
> numbers easier to memorize).
>
> 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).
>
> 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.
>
> Regards,
> Eduard Pascual
>
> Phone numbers can also validly include pause characters too. I remember back
> in the day saving such a number to quickly dial into my voicemail, rather
> than having to dial in, wait for the automated voice, press a digit, wait for
> some more robot speaking, press another number, etc.
>
> Also, not entirely sure, but would asterisks (*) and hashes (#) be included
> too? I was just going on what digits exist on a standard phone keypad.
So it seems that I was indeed too hasty with my proposal. Let me put
aside the specifics and focus on the idea:
- Issue: there is no explicit "standard" to represent phone numbers
that works on a world-wide scale.
- Fact: there is an implicit "standard" that defines what a phone does
(where does it call) depending on which sequence of keys is pressed.
- Idea: given the need for a standard, and the lack of an explicit
one, use the implicit one that can actually work. I was hasty and
provided an incomplete definition of that implicit standard; but I'm
quite convinced a correct definition can be produced with a bit of
research and effort.
On Wed, Apr 7, 2010 at 1:48 AM, Davis Peixoto <davis.peix...@gmail.com> wrote:
>>
>> 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).
>
> This goes in the opposite direction from the initial idea of creating a
> interface that intend to avoid type mismatches, unfortunately.
Actually, it doesn't. It just goes nowhere from the starting point
(pre-HTML5, phones are <input>ed as raw text, which provides no
phone-specific interface).
Current HTML5 approach, however, does go in that opposite direction,
since allowing UAs to add whatever they wish is nowhere near to avoid
the mismatches, and it's even guaranteed to trigger them when the UA
fails to second-guess what the page expects. The most obvious scenario
I could come up with is that of a user using a foreign computer (I
quite know what I'm speaking about here, I have struggled so many
times with Irish keyboards to get a 'ñ' through ^^' ); for example:
the user may be attempting to input a Spaniard number in a Spaniard
site, and the UA might be trying to enforce Irish phone-number
conventions: this may break even if the site itself is up for the
battle and attempts to remove all the extraneous characters, since it
could quite make sense to prepend a '0' to an Irish number (not very
advisable for an UA to do that, but possible since it may be needed to
dial an extra '0' on some situations). Also, things will definitely
break if the site expects Spaniard formatting (just some spaces, and
perhaps a bracket pair) but the UA enforces a different formatting
convention (the break isn't guaranteed for the Irish UA example if it
goes with spaces, but as far as I've seen in that country spaces and
hyphens are used quite interchangeably).
The goal of fool-proofing phone fields is a quite noble one but, let's
be honest: it's quite near to an utopia. Any "solution" that may cause
valid inputs to break is definitely bad. If fixing wrong inputs risks
valid ones to break, we are not only not solving the problem, but we
are moving it somewhere it doesn't make sense: if you had to choose
between wrong inputs breaking or good inputs breaking, is there any
sane reason to chose the later?
I'll admit: of my two original suggestions, one had mistakes (see my
reply to Ashley above) and the other doesn't gain anything. However,
the current "solution" not only doesn't gain anything, but it also
loses.
Regards,
Eduard Pascual
