You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I learned about the following difficulty with the tel-country-code autocomplete type:
Many websites rely on a <select> element to let users choose their telephone country code. Oftentimes the <option>s look as follows <option value="...">United States (+1)</option>.
The website cannot put "+1" in the <option> value because there would be a collision:
<option value="+1">Anguilla (+1)</option>
<option value="+1">USA (+1)</option>
The browser would probably just use the first match of +1 (Anguilla) when trying to fill a phone number.
As a result, websites may prefer the following to get a better autofill experience.
Unfortunately, using autocomplete="country" is semantically incorrect when you are trying to fill a phone number. The user might have a UK phone number associated with a US address.
I don't know whether there's a perfect way of fixing this.
I guess my preference would be to suggest that <select autocomplete="tel-country-code"> supports selecting entries via the their 2-letter ISO-3166 codes in the examples section.
Alternatively, we could introduce an autocomplete="tel-country-code-ISO-3166-1-alpha-2" which does not select countries via their calling codes but via their 2-letter ISO-3166 codes?
A challenge for implementers is that telephone number country code may not be associated with any specific country, it's just a raw number (+1). I would propose a heuristic (not for the spec):
Given an address A that should be filled, lookup the country code (lookup_country) of A.country (e.g. "US") from a table, (which would give us "+1". for A.country == "US")
If lookup_country lookup matches A.phone_country_code, try to select the <option value="$lookup_country">
Else, do a reverse lookup for candidate 2-letter country codes from A.phone_country_code, select one (selected_country) using some heuristics and try to find the <option value="$selected_country">.
If that failed, try other heuristics to find the correct <option>.
The text was updated successfully, but these errors were encountered:
I learned about the following difficulty with the
tel-country-code
autocomplete type:Many websites rely on a
<select>
element to let users choose their telephone country code. Oftentimes the<option>
s look as follows<option value="...">United States (+1)</option>
.The website cannot put "+1" in the
<option>
value because there would be a collision:<option value="+1">Anguilla (+1)</option>
<option value="+1">USA (+1)</option>
The browser would probably just use the first match of +1 (Anguilla) when trying to fill a phone number.
Unfortunately, using
autocomplete="country"
is semantically incorrect when you are trying to fill a phone number. The user might have a UK phone number associated with a US address.I don't know whether there's a perfect way of fixing this.
I guess my preference would be to suggest that
<select autocomplete="tel-country-code">
supports selecting entries via the their 2-letter ISO-3166 codes in the examples section.Alternatively, we could introduce an
autocomplete="tel-country-code-ISO-3166-1-alpha-2"
which does not select countries via their calling codes but via their 2-letter ISO-3166 codes?A challenge for implementers is that telephone number country code may not be associated with any specific country, it's just a raw number (+1). I would propose a heuristic (not for the spec):
A
that should be filled, lookup the country code (lookup_country
) ofA.country
(e.g. "US") from a table, (which would give us "+1". forA.country == "US"
)lookup_country
lookup matchesA.phone_country_code
, try to select the<option value="$lookup_country">
A.phone_country_code
, select one (selected_country
) using some heuristics and try to find the<option value="$selected_country">
.<option>
.The text was updated successfully, but these errors were encountered: