On Thu, 29 Jul 2010, Mounir Lamouri wrote:
> On 07/29/2010 12:08 AM, Ian Hickson 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
On 07/29/2010 12:08 AM, Ian Hickson 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
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,
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 firs
Ashley Sheridan wrote:
> On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
>
>> On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson 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
Am 07.04.2010 01:28 schrieb Eduard Pascual:
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
On 07/04/2010, at 9:21 AM, Mounir Lamouri wrote:
> When I was using MacOS X, I hated how the contact application was
> restyling my phone numbers.
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 t
>
>
> 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
On Wed, Apr 7, 2010 at 1:31 AM, Ashley Sheridan
wrote:
>
> On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
>
> On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson wrote:
> > If there was a true standard, then the spec would refer to that, but as
> > you say, it's very varied in practice.
>
> The
0-9, *, #, p, w
http://www.wikihow.com/Add-Pauses-to-a-Phone-Number
recognizing the difference between a 'P' and a 'p' (or a 'W' and a
'w') is moderately painful.
>
>
> 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
On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
> On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson 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
>
> When I was using MacOS X, I hated how the contact application was
> restyling my phone numbers.
> By the way, it lets me think about something: the telephone state can
> still be used for autocomplete with phones from contacts.
>
> --
> Mounir
>
Good one, Mounir.
Tab, this does not means onl
On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson 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 someo
On 04/07/2010 01:18 AM, Tab Atkins Jr. wrote:
> On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri
> wrote:
>> 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 us
On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri wrote:
> 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
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.
>>
>
On Tue, 6 Apr 2010, Davis Peixoto wrote:
>
> Thing is UA is allowed to do that, but without clear rules, this can be
> a mess. If for date and time, where we have a lot of formats and
> standards for internationalization, how can UA specify and be no type
> mismatch, if we do not have any stand
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
Hello fellas,
I agree with Mounir.
Thing is UA is allowed to do that, but without clear rules, this can be a
mess.
If for date and time, where we have a lot of formats and standards for
internationalization, how can UA specify and be no type mismatch, if we do
not have any standard about phone nu
On 04/07/2010 12:55 AM, Ian Hickson wrote:
> On Wed, 7 Apr 2010, Mounir Lamouri wrote:
>> On 04/07/2010 12:37 AM, Ian Hickson wrote:
>>> On Tue, 6 Apr 2010, Mounir Lamouri wrote:
For input element in telephone state [1] specs say "User agents may
change the punctuation of values tha
On Wed, 7 Apr 2010, Mounir Lamouri wrote:
> On 04/07/2010 12:37 AM, Ian Hickson wrote:
> > On Tue, 6 Apr 2010, Mounir Lamouri wrote:
> >>
> >> For input element in telephone state [1] specs say "User agents may
> >> change the punctuation of values that the user enters." I do not really
> >> get
On 04/07/2010 12:37 AM, Ian Hickson wrote:
> On Tue, 6 Apr 2010, Mounir Lamouri wrote:
>>
>> For input element in telephone state [1] specs say "User agents may
>> change the punctuation of values that the user enters." I do not really
>> get it. What is the idea ?
>
> For example, if I enter "1
On Tue, 6 Apr 2010, Mounir Lamouri wrote:
>
> For input element in telephone state [1] specs say "User agents may
> change the punctuation of values that the user enters." I do not really
> get it. What is the idea ?
For example, if I enter "1 650 253-", the user agent is allowed to
change
On Tue, 2010-04-06 at 23:12 +0200, Mounir Lamouri wrote:
> Hi,
>
> For input element in telephone state [1] specs say "User agents may
> change the punctuation of values that the user enters." I do not really
> get it. What is the idea ?
>
> [1] http://dev.w3.org/html5/spec/forms.html#telephone-
Hi,
For input element in telephone state [1] specs say "User agents may
change the punctuation of values that the user enters." I do not really
get it. What is the idea ?
[1] http://dev.w3.org/html5/spec/forms.html#telephone-state
Thanks,
--
Mounir
26 matches
Mail list logo
