Re: [whatwg] Changing punctuation value of input element in telephone state
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 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. > > It is, unless an author adds a pattern because he/she wants the > telephone number in a specific format (including spacing) which is > suggested by the specifications. In that case, if the user can't cancel > UA's autoformatting, it could be really bad for user experience. > > I'm just worried about that case. If you consider it's not a > specification problem (ie. UA should let users disable autoformatting), > it's ok. Certainly the user agent should not take input that matches the pattern and autoformat it into a string that doens't match the pattern. But that seems like a quality of implementation issue, not a spec issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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. It is, unless an author adds a pattern because he/she wants the telephone number in a specific format (including spacing) which is suggested by the specifications. In that case, if the user can't cancel UA's autoformatting, it could be really bad for user experience. I'm just worried about that case. If you consider it's not a specification problem (ie. UA should let users disable autoformatting), it's ok. Thanks, -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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).
Re: [whatwg] Changing punctuation value of input element in telephone state
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.
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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).
I mostly agree. Number grouping and punctuation is part of the
formatting, not real content.
> Phone numbers can also validly include pause characters too. [...]
>
> 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.
I think that asterisk and hash are required for some internal phone
numbers, though somewhat rare. The "+" sign can usually be replaced with
double zero, but if I've understood correctly, the "+" is technically
different from double zero in the phone network.
There's an extra issue with pauses as far as I know:
US notation (CDMA?):
"," pause for 1 second
"p" pause for 3 seconds
GSM notation:
"p" pause for 3 seconds
"w" wait for any key press, do not transmit the pressed key
In addition to these issues, at least in Finland the traditional
formatting of long distance codes in addition to country codes result in
totally insane formatting. Example:
Local phone number (usual formatting):
1234 567
When dialing, you just press 1234567
With long distance code (still usable inside Finland only):
(012) 1234 567
[traditionally you used the "012" prefix only if "012" was not your own
prefix, it was not possible to use "012" prefix optionally if you lived
in "012" area]
When dialing, you just press 0121234567
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.
Fortunately, it seems that this problem is a self fixing one: younger
generation does not understand the history behind this mess and they
will only know the no-visible-punctuation-characters format so they will
either enter "+358121234567" or "+358 12 123 4567".
In the end, I think that sensible choice would be to specify that
type="tel" is identical to type="text" except that the UA could suggest
phone numbers from the phone book instead of any random input from other
previously inputted text. The UA could even display the name in addition
to the number if it recognizes that the number that user just inputted
is in fact one found in the phone book. I don't think it's currently
internationally safe to automatically change the user input in any way.
--
Mikko
signature.asc
Description: OpenPGP digital signature
Re: [whatwg] Changing punctuation value of input element in telephone state
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 the field. I would actually expect sanitizing phone numbers to be done by the applications that use the numbers rather than by the application that collects them. If I collect a phone number and store it in a database, there might be several usages for them, e.g.: 1. Print out a list of numbers for manual dialling 2. Show a user record on screen, dial manually 3. Show a user record on screen, the phone number is linked for automatically invoking Skype or whatever application on click 4. Export phone numbers to an external application For usages 1. and 2., the machine-readable sanitized number format might be a hassle, the unchanged user format will be preferred. Also, if a user loggs in to any application and is prompted to check her/his user data, the phone number will be expected to be shown in the same format as entered. That's why I think phone numbers should be submitted unchanged in any case. Even for validation purposes, locale-based patterns are likely to be a problem, e.g. if you try to enter your US-phone number from an internet cafe in Bombay.
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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. When it comes to applying formatting, the OS X Address Book (apparently) does it as follows: 1. Don't apply any format while the field has keyboard focus (least surprise) 2. When the field loses focus, the OS checks the number of digits in the input and compares that to the formats defined in the preferences. If no format is defined for that number of digits, don't change the input at all. 3. If (at least one) format exists for the number of digits entered, apply the format to the input In practice there are two things I feel the OS X Address Book does unexpectedly: 1. I would suggest that if the user enters his or her input including spaces and/or parentheses, those should be maintained (perhaps this is deliberate to allow the pasting/data detection of arbitrary formatted content into the field, but in practice it means I can't override a format for a single number) 2. If two formats are defined for the same number of digits, only the first is applied (in eastern Australia, there are two conventions for 10-digit phone numbers; landlines are defined as, for example, ## whereas mobiles are in the format ### ###). If I define each of those formats as custom formats, only the first in the list is applied for 10-digit numbers (even if I enter the number precisely following the other format). To work around that issue, I have to define the format as "04## ### ###", which works in Australia but might be too restrictive for some other cultures. Cheers, Kit Grose User Experience + Tech Director, iQmultimedia (02) 4260 7946 k...@iqmultimedia.com.au iqmultimedia.com.au
Re: [whatwg] Changing punctuation value of input element in telephone state
> > > 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? > This is what I was saying. It is noble, but utopic (Yeah, you put it better in words). But now I realized: UA handling of type=tel is just a possibility, not a mandatory feature. Thus, I think even it is documented in somewhere in HTML 5 spec, it won't be used/implemented at all due to all the drawbacks we were discussing about in this thread. -- Hugs, Davis
Re: [whatwg] Changing punctuation value of input element in telephone state
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.
>
> 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 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 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 d
Re: [whatwg] Changing punctuation value of input element in telephone state
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.
Re: [whatwg] Changing punctuation value of input element in telephone state
> > > 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. > > 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. > I just mentioned another drawback. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [whatwg] Changing punctuation value of input element in telephone state
> > 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 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. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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 ? > > Mobile phones seem to get by ok with restyling the phone numbers you > type into them. If you want to emulate that in your app (or > conversely, if you want to create a phone UI in HTML5), you'll need > the freedom to restyle the phone number in that way. > > Of course, I'm from the US, and don't know if someone from another > country is annoyed at all the US-centric phone-number formatting their > phone is automatically doing. 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
Re: [whatwg] Changing punctuation value of input element in telephone state
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 or 4-digit blocks. > Maybe the telephone type can be like the search one and be here only for > styling ? Mobile phones seem to get by ok with restyling the phone numbers you type into them. If you want to emulate that in your app (or conversely, if you want to create a phone UI in HTML5), you'll need the freedom to restyle the phone number in that way. Of course, I'm from the US, and don't know if someone from another country is annoyed at all the US-centric phone-number formatting their phone is automatically doing. ~TJ
Re: [whatwg] Changing punctuation value of input element in telephone state
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 ? -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
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 standard about phone numbers? > > I mean, american format differs a lot from brazilian, which differs a > lot from indian, which differs from... you got it. > > But it would be great if this kind of data becomes part of i18n > packages, meaning that any user, with a UA tunned to its native language > can input that, and let it do the job, like for date and time. > > However, not like date, which is a fixed number, phones can vary a lot > from one region to region in length, and prefixes. > > I think this is open to UA devs and RFC writers to take care, but I am > not sure if these statements will be useful someday at all due this lack > of pattern among regions. If there was a true standard, then the spec would refer to that, but as you say, it's very varied in practice. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
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. > I've opened bug 9439 about this issue. Right-o. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
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 numbers? I mean, american format differs a lot from brazilian, which differs a lot from indian, which differs from... you got it. But it would be great if this kind of data becomes part of i18n packages, meaning that any user, with a UA tunned to its native language can input that, and let it do the job, like for date and time. However, not like date, which is a fixed number, phones can vary a lot from one region to region in length, and prefixes. I think this is open to UA devs and RFC writers to take care, but I am not sure if these statements will be useful someday at all due this lack of pattern among regions. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
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 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 that to "+1 (650) 253 " or "1650253" or "+1 (650) >>> 253-". This is because such reformatting is common practice in >>> telephone number entry fields. >> >> I understand this is common but as the UA is "allowed to" behave a >> certain way, it is going to be really hard for the webpages to check the >> telephone numbers validity. With the example you gave, for one entry, >> three different values have been generated. >> In my opinion, this is the contrary of the spirit of no type-mismatch >> constraint validation. > > 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()). I've opened bug 9439 about this issue. -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
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 it. What is the idea ? > > > > For example, if I enter "1 650 253-", the user agent is allowed to > > change that to "+1 (650) 253 " or "1650253" or "+1 (650) > > 253-". This is because such reformatting is common practice in > > telephone number entry fields. > > I understand this is common but as the UA is "allowed to" behave a > certain way, it is going to be really hard for the webpages to check the > telephone numbers validity. With the example you gave, for one entry, > three different values have been generated. > In my opinion, this is the contrary of the spirit of no type-mismatch > constraint validation. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
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 650 253-", the user agent is allowed to > change that to "+1 (650) 253 " or "1650253" or "+1 (650) > 253-". This is because such reformatting is common practice in > telephone number entry fields. > I understand this is common but as the UA is "allowed to" behave a certain way, it is going to be really hard for the webpages to check the telephone numbers validity. With the example you gave, for one entry, three different values have been generated. In my opinion, this is the contrary of the spirit of no type-mismatch constraint validation. -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
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 that to "+1 (650) 253 " or "1650253" or "+1 (650) 253-". This is because such reformatting is common practice in telephone number entry fields. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
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-state > > Thanks, > -- > Mounir I would assume that to mean that if a user enters a number with hyphens to separate the different parts of the number (area code, state code, country code, etc) then the UA could strip those out or re-format the string? Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] Changing punctuation value of input element in telephone state
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
