Recently, Lea Verou asked an important question about whether HTML should have a standardised way of letting users select a country from a list.
HTML Idea: <input type="country"> which would become a searchable dropdown with all countries and their flags.
Wouldn't that be awesome?— Lea Verou (@LeaVerou) October 21, 2017
You can read through the conversation and make your own mind up (while also marvelling at the witless mansplainers) - but I'd like to give you my considered take on it.
(Disclaimer - I'm an editor on the HTML 5.3 spec and I work for the UK Government. This is a personal blog post and doesn't represent the views of my employers, associates, or friends.)
Who Are You?
Let's start with the big one. What is a country? This is about as contentious as it gets! It involves national identities, international politics, and hereditary relationships.
Scotland, for example, is a country. That is a (fairly) uncontentious statement - and yet in drop-down lists, I rarely see it mentioned. Why? Because it is one of the four countries which make up the country of the United Kingdom - and so it is usually (but not always) subsumed into that.
Some countries don't recognise each other. Some believe that the other country is really part of their country. Some countries don't exist.
There are two main schemes to classify what is and isn't a country. The first is ISO 3166-1. It provides two- and three-letter codes for every country. Well... sort of.
ISO 3166 contains 249 different countries, territories, protectorates, principalities, duchies, and other bits-and-bobs. It contains the Falklands, but not Scotland.
The second is... whatever your country says is another country!
My friends in the Government Registers Team have published a canonical list of every country that the UK recognises. There are 199 entries. Which countries are not in there is left as an exercise for the reader.
The UK's register of countries should allow every Government website to have the same list in a drop down. When new countries are recognised, one list needs to be updated - and then all websites automagically update. In theory.
Incidentally, that list of 199 countries includes four entries for countries which no-longer exist. For example Yugoslavia.
Which brings us to the next question...
What's the use case?
The most obvious one is "I want to give a site my current address" - presumably for identification purposes or postal deliveries.
But what if the use case is "I want to say where I was born"?
Borders shift. Countries disappear, merge, split, change names, change flags, and do all manner of weird things which trip up your edge cases.
The user may want to find the name in their own script - for example would a Greek user be looking for "Greece" or "Ελλάδα"? If a Chinese speaker wants to visit the UK, do they look in the drop-down for "英国"?
International Dialling Codes - not every country is unique - +1 is used by USA, Canada, Anguilla, Dominican Republic, and dozens more. Are there countries where there is more than one international dialling code?
OK, what if the user wants to select their language based on their country?
Do You Have A Flag?
It is one of the classic conventions that first-year students of user interface design are taught - countries do not represent language!
Some countries have multiple official languages. Some users may not speak the language of their country. Some languages are only used for official purposes, and not by the general population.
Flags mostly represent countries. There are people in Wales who would rather see Y Ddraig Goch rather than the Union Jack. And vice-versa. Flags can make people angry.
The flag of the USA last changed in 1960 - but Mauritania changed theirs in August 2017. How quickly can a browser update their list of countries?
...and yet...
I instinctively like this idea! This isn't a new question, nothing ever is, but I think it is an idea which has merit.
One of the goals of HTML is to stop web developers having to re-invent the wheel. That's why we have lots of different <input> types - to reduce complexity.
Colour picker
Number inputs
Range selector
Some modern browsers support date input
The challenges of a country selector are...
- Keeping everyone happy and not causing major diplomatic incidents. Easy‽
- Usability. Making sure it's easy to search for the name of a country.
- Consistency. How do you indicate that this list contains historic countries?
None of these are insurmountable problems - but it's far from trivial.
And yet... I think there is a real possibility that this could work. Millions of websites already find ways to cope with the ambiguity - perhaps browsers can too?
Possibly relevant:
"Fill Autocomplete From Wikidata api by passing Category"
https://stackoverflow.com/questions/35593986/fill-autocomplete-from-wikidata-api-by-passing-category
Perhaps someone could refactor that to limit results to those in a specific Wikidata query ("countries with an ISO code", "countries that existed in 1988", etc.)
I'm obliged to Dan Brickley who recently drew my attention to the linked discussion.
That would be open to abuse. Sure the vandalism wouldn't stick, but what about people getting the cache for the first time while the article is vandalized. I could see Taiwan getting trolled.
Belated reply: but Wikidata can, and does, protect items that are subject to vandalism, so that only trusted users can edit them.
I've just built something that needed a "Country" specified and I used a datalist for suggestions on the front end and, when posted to the backend, multibyte lower cased it and tried to match it against a stored similar list (based on the ISO list) to generate the stored "country code". Allowed people to enter what they would like (and the list could have "England"->"GB", "Scotland"->"GB" and multiple language "英国"->"CN" ) and made a best effort match. Having the datalist suggestions contain all possible permutations would be difficult though and sometimes users need guidance what they are expected to type...
But, as you brought up, it's "why" you need the country which can be the issue. Delivery/current location is usually the use case, but (as your brought up) asking where someone was born when borders change can be an issue - an Estonian born in 1944 could be presented with "Germany", "Soviet Union", or "Estonia" and all could be technically correct and all be offensive to them at the same time. Grrr...
Keeping everyone happy and not causing major diplomatic incidents. Uh-oh.
Yup. Now that you've mentioned the Falklands - those should sort under "M" (for "Malvinas"), everyone* knows that, right? Don't get me started on that farce of a name that hides under the acronym FYROM, either. And, btw, some existing and recognized countries have an ISO-3166 shortname which its populace mostly considers offensive ("Czechia"). Yeah. Easy peasy.
Not to mention the previous half-baked browser-specific solutions such as input=date...nope, I don't have any hope for this proposal.
(Everyone in Argentina, that is.)
Thank you for writing this up Terence!
Some ideas about the challenges you present:
I like the idea of only displaying the countries the current country recognizes, that prevents most issues with getting browsers banned etc.
Alternatively, what if there were attributes for year and location to customize the list of countries based on the year and a base country that recognizes them? The year would default to the current year, and the base country would default to the current country. A "*" value might be useful to get the union of all lists (i.e. all countries)
We should explore if there's a way to get a list of countries from the OS. This would also solve the issue by deferring it to the OS.
Regarding localization, another possibility to consider is to localize to the computed lang of the element, instead of the browser language. Not sure if that's better or not.
An dropdown entry with 300 choices can be as hard to use as this browser's built-in date input - if I want to enter a date before 1970 or so the years and months scroll past so fast it's an exercise in dexterity and most times when i let go the date isn't updated!
To get round this for countries you can usually type the first letter or two, although that's not going to work so well for Chinese...
A list that has recent values and one's current location (and maybe, if known, one's home country) duplicated at the top, as some word processors do for a fonts list, would be workable.
BUT input type=country with autocomplate but where the user can override the value, and falls back to a plain text field, seems to get around a lot of the problems.
How about giving the picker a "src" attribute that takes the URL of a document in a prescribed format. If the attribute is omitted or invalid, or the document is malformed, fall back to an internal default list for the browser.
This would allow the UI to remain the same (with searching, sorting or whatever), but let the page author use an alternative list of values. Governments or other bodies could set up "authoritative" lists, but page authors can still use historical lists, shortened lists ("countries we ship to"), or extended lists which are hosted at a more local URL.
This is a great post. Some of the issues you raise here are similar to your previous posts on family structure and name input. At first glance they seem like simple problems, but very quickly layers and layers of complexity set in.
I've worked on visa systems in the past, and country lists are a complex and time consuming part of system definition and testing. For instance one system I worked on had different lists for country of residence, country of passport issuance, country of birth and country of citizenship. The middle two categories have to include countries that are no longer countries (e.g. Netherlands Antilles). The country of issuance includes non-countries (e.g. the UN and agencies) and doesn't include some countries (e.g. Cook Islands). The final category needs to include an option for 'stateless' and other specific categories. That's before you even get to the mess that is what countries recognise other countries (e.g. South Sudan).
Why does this matter? Well this type of browser list may be used by airlines for checkin system, for financial services in opening or accessing accounts, or for voter registration. It's very easy for these types of well meaning lists to systematically disenfranchise people from online services.
PS One other issue I've noticed with this type of implementation is sort order, especially in translation. One county's eVisa system decided to sort on ISO country code whilst displaying full name. Hence the United Kingdom appearing between Gabon and Granada!
and input type="language"
and textarea type="wysiwyg" too for a fast rich text editing.
What if the form author could simply indicate that they are looking for a country and let the the browser decide what the options are? The browser could also decide what the best "type" of field is (searchable dropdown, dropdown, etc..)
Ultimately the data returned by the form would be a string, any value is valid, the idea is just to help user experience.
I was wondering if, its so hard to use the html5 inputs. Date Input, for example, its kind of different on every browser. The datatype (value) is different, some international issues (date format, time format, value). If is an input type="country", what will be the value? whom pattern (ISO 3166, ISO 3166-1, ISO 3166-2...?). What if you need to exclude or disable some countries? Its kind common select a better and more customizable solution for that. If you wanna flags, use radio stead of
Ah, the perils of global scope
I think input="country" might be a good addition to the HTML5 input collection. However, I see developers don't use new input types too much, such as color picker, datetime, etc. The support and especially UI for these inputs are still limited. I hope browsers Google Chrome, Firefox, Safari and Edge provide a consistent UI for those field types.
I agree that this feature isn't necessary. Nested s would be far more useful.
But I do wonder if browsers have timezone information that effectively recognises countries... does anyone know?
Anyway, showing 200 countries in a is no big deal, and I guess emojis could be used for the flags (or background images if they need to be custom). It doesn't seem like a problem that developers really suffer under.
Pourquoi ne pas mettre tous les choix possibles, historiques, langues, actuels, pour une livraison ou pour tout autre chose (exemple dans la liste il y aurait Yougoslavie aussi bien que Kosovo ou UK et écosse.) chacun choisirai dans la liste le pays qui conviendrait à son cas particulier. La liste serait longue mais par ordre alphabétique. Et si quelqu'un ne trouve pas son bonheur, il pourrait l'ajouter par lui-même.
I do not see input="country" as a very good solution to problems that go far beyond just a method of masking data entry. Because (in the end) a location is asked for, a place of residence, place of birth, delivery address, etc., you can avoid problems by having people put a marker on a map. On the backend you can match these coordinates with what is needed for handling the request in both time and location. I would be from Lugdunum Batavorum in 275 BC!
To make everyone happy the supposed input[type="country"] should contain all the countries from some kind of standard and allow attributes to insert other countries and remove unwanted ones. The language/alphabet should be the browser's one.
Also worth thinking about is the Mobile version, showing the keyboard and a list of countries/flags will take up the whole screen. Could the Keyboard be there with auto complete showing flags, so when I type Unit[ed States] it could show me flags for UAE, US, UK etc. Needs thought.
There should be a
<
div class="website">. to just generate a website for me.
A little bit of a shitpost, but nevertheless...I do think this goes beyond HTML's domain. HTML isn't there to make it easy for web developers - HTML is a way to communicate to a browser as well as accessibility tools how to display web documents.
HTML should be as bare bones as necessary. HTML input pickers makes sense because they restrict on certain types of fundamental data. I'm of the opinion that even "date" might be going beyond the scope, but I can understand it's probably making life for mobile users much easier.
What about something like
[select type="external" src="https://domain.com/src.json"]][/select]
Where the JSON source might be something like
{
"key1": "val1",
"key2": "val2",
"key3": "val3"
}
This could be used for country, but for almost any other data as well.
To me, this is a place where Web Components have a lot of potential. Without trying to bake something like this into the HTML spec, there can be many implementations of such an input, which could be used regardless of the front-end tech a project is using.
Having worked with creating components for forms I can tell you this is something we re-invent over and over and over – the same with color pickers.
Adding a "searchable" attribute to the element would allow other types of long lists (e.g. job title, client, project) to benefit from being able to filter down the results as well instead of country being the only one that benefits.
This would also give developers an easy method of implementing country selectors until a propper input[type=country] is able to be figured out which I expect would take much longer to implement.
I found the question interesting, for the use cases could really bring practicality but I think it is impracticable through a specification and unlikely that developers of browsers implement.
An Open Source library with an active community and up-to-date (or historical) data in a public JSON would be exceptionally more useful. A JavaScript (or other) language could easily handle groups, allowed or blocked listing, or even a custom entry that could display country flags.
I particularly use ISO 3166-1 alpha-2 on "select" elements since this ISO is usually the default internet since this is the default used in DNS (ccTLD)
The reason for not finding Scotland in ISO 3166 and its derivations is given to the fact of reservation:
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Exceptional_reservations