datalist on safari

Datalist element

Method of setting a list of options for a user to select in a text field, while leaving the ability to enter a custom value.

• 4 - 19 : Not supported (but has polyfill available)
• 20 - 68 : Partial support
• 69 - 122 : Supported
• 123 : Supported
• 124 - 126 : Supported
• 12 - 15 : Partial support
• 16 - 18 : Partial support
• 79 - 122 : Supported
• 3.1 - 12 : Not supported (but has polyfill available)
• 12.1 - 17.3 : Supported
• 17.4 : Supported
• 17.5 - TP : Supported
• 2 - 3.6 : Not supported (but has polyfill available)
• 4 - 101 : Partial support
• 102 - 109 : Partial support
• 110 - 123 : Supported
• 124 : Supported
• 125 - 127 : Supported
• 9 - 12.1 : Supported
• 15 - 63 : Partial support
• 64 - 108 : Supported
• 109 : Supported
• 5.5 : Not supported
• 6 - 9 : Not supported (but has polyfill available)
• 10 : Partial support
• 11 : Partial support

Chrome for Android

Safari on ios.

• 3.2 - 12.1 : Not supported (but has polyfill available)
• 12.2 - 17.3 : Supported
• 17.5 : Supported

Samsung Internet

• 4 - 23 : Supported
• 24 : Supported
• all : Not supported

Opera Mobile

• 10 - 12.1 : Supported
• 80 : Supported

UC Browser for Android

• 15.5 : Supported

Android Browser

• 2.1 - 4.4 : Not supported (but has polyfill available)
• 4.4.3 : Supported

Firefox for Android

• 124 : Not supported
• 14.9 : Supported

Baidu Browser

• 13.52 : Supported

KaiOS Browser

• 2.5 : Not supported
• 3 : Not supported

While most commonly used on text fields, datalists can also be used on other input types. IE11 supports the element on range fields. Chrome and Opera also support datalists to suggest given values on range , color and date/time fields.

Using the Datalist to Provide Guided and Auto-Suggest Values for Form Input Fields

Last Updated - Sat Jan 09 2021

The HTML datalist control pairs with an input to provide simple, semantic solution to provide a currated value list for users to provide a value without typing. This is particularly useful for mobile interfaces because it eliminates an error prone typing experience.

The most common use of the datalist is to create a nice autocomplete experience. Without the datalist you must craft a more complex solution that leans more on slower JavaScript and hacky HTML and CSS. The combination of an Input and datalist controls gives you a slick, native option.

Guided user input is a good data entry user experience. You want to help the user avoid potential mistakes. It also helps que the user about valid values the field is expecting.

With on screen, mobile keyboards you want to reduce the keystrokes required to enter data and at the same time make sure the data entered is at least valid if not absolutely correct.

Ever since Google first introduced a little search phrase suggestion to their home page several years back the notion of an auto-complete has become popular. There are many tutorials around the Internet about how you can implement this simple piece of AJAX magic.

HTML5 added support for many useful form/data entry enhancements. One that does not get much attention is the datalist element. This element acts as a placeholder for a native browser auto-suggest feature.

The recent Apple Safari update finally included support for this native input solution, so now you can safely use this element without needing a clunky polyfil .

Where most AJAX auto-suggest plugins and libraries inject or leverage an absolutely position element containing the list of potential values, the datalist handles this natively.

You can associate most input field types to a datalist element. I have also found it possible to associate multiple inputs to a single datalist.

The association between an input field and a list is made by setting the input's list attribute to the id of the target datalist. This of course means you need to provide a unique id for each datalist.

The list attribute is not supported by the hidden, password, checkbox, radio, file, or any of the button types. Any value that does not match the input element's type is not included in the possible values displayed to the user.

For example a list of emails, like I use in the demos, wont be displayed when the input type if number.

Pre-Populated datalist Options

You can pre-populate the datalist if you want. The datalist should contain a list of Options, similar to the Select element.

Each Option's value will be used to display in the list. When the user selects an item from the auto-suggest list the value is placed in the active INPUT field.

In this example I have pre-populated the list so the suggested values are available as the page is rendered.

A datalist element can be placed anywhere in the markup, but you associate the target input element by adding a list attribute. The list attribute's value is the 'id' of the related datalist.

Once this relationship is established the user will have access to the suggestion list. In Chrome and the new Edge there is a dropdown arrow in the right-hand side of the input field. FireFox displays nothing, but the user can double-click to display the list.

All browsers will display a list of possible values as the user types. This will be the most common method to trigger the datalist support.

As the user types the list filters to display only values that match the entered phrase.

Dynamically Adding datalist Options Using AJAX

The datalist does not need to be pre-populated. You can dynamically add items at run-time. This means you can wire an AJAX/Fetch based solution to feed data to the option list.

In this example I bind a list of e-mails to the datalist when focus is set to the targeted input.

I simplified this example to demonstrate how to bind a list of possible options at run-time. The example code has a JSON object with the values for both this e-mail example.

I think the best part of this solution is you can fetch a valid list of values as the user focuses on the field or loads the form. As they type the browser will filter the list to only values matching the entered characters.

This save you, the developer from needing to create a custom filtering solution. It also does not restrict you from doing so either. You can always refresh the datalist values based on your own criteria.

To do so you would need to do a little refactoring to extract the logic to bind the list to the datalist into its own method.

In this code snippet I have extracted the logic to bind the list into its own function (visit the GitHub repo for actual code) and added a 'keyup' event handler to dynamically update the list.

I did need to make a change to the bindEmailList method to clear the list of child elements before a new set was added.

You should add the following to the code to keep the list from growing exponetially and including duplicate values.

I added this code just before the loop starts.

datalist vs Select or Classic Dropdowns

You may be wondering why you would use an Input + datalist solution instead of the Select element?

This is a great question because there are similar, but different and you need to understand when one is more appropriate than the other.

The main difference between the datalist and Select elements is the ability to enter a value not included in the option list. The datalist allows the user to enter any value, assuming it meets validation criteria, and the select element restricts values to those in the option list.

If you think about a typical autocomplete scenario, the suggestions are either based on the user's history or a list of options based on an algorithm. This does not mean the choices are what the user wants to enter.

If you think about using a search engine, each one has a search suggestion list as you type based on related searches others have previously entered. This may not be the search phrase you need, so you are allowed to submit anything.

If search engines used the Select element the range of search phrases would be extremely limited and you most likely would not find an acceptable result for your query.

For the record about 20% of the daily queries submited to search engines have never been submitted before. That means at least 1/5 of the daily search traffic would not exist, well not in its current form at least.

Wrapping It Up

The datalist element is a very helpful tool to guide users to the correct value.

Because it is native to the browser it includes common auto-suggest functionality for pesky data entry tasks. You should always make an effort to make data entry easy and the datalist element is a great tool to make a frustrating form much easier to use, increasing productivity, sales conversions and overall user satisfaction.

I particularly like this option because it is a native control and thus helps us eliminate slower JavaScript options. It is always good when you can remove JavaScript from a web page so you can provide a faster user experience.

The native solution also provides additional advantages as browsers have smart filter/auto-complete logic and filtering that make it easier for us to deliver a better solution faster with less testing required.

I encourage you to start adding the datalist element to your data entry forms. It is a great way to enhance your progressive web applications .

You can find my simple Datalist example inside my Love2Dev Samples Repo on GitHub .

We use cookies to give you the best experience possible. By continuing, we'll assume you're cool with our cookie policy.

Install Love2Dev for quick, easy access from your homescreen or start menu.

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free
• English (US)

<datalist>: The HTML Data List element

The <datalist> HTML element contains a set of <option> elements that represent the permissible or recommended options available to choose from within other controls.

To bind the <datalist> element to the control, we give it a unique identifier in the id attribute, and then add the list attribute to the <input> element with the same identifier as value. Only certain types of <input> support this behavior, and it can also vary from browser to browser.

Note: The <option> element can store a value as internal content and in the value and label attributes. Which one will be visible in the drop-down menu depends on the browser, but when clicked, content entered into control field will always come from the value attribute.

This element has no other attributes than the global attributes , common to all elements.

Textual types

Recommended values in types text , search , url , tel , email and number , are displayed in a drop-down menu when user clicks or double-clicks on the control. Typically the right side of a control will also have an arrow pointing to the presence of predefined values.

Date and Time types

The types month , week , date , time and datetime-local can show an interface that allows a convenient selection of a date and time. Predefined values can be shown there, allowing the user to quickly fill the control value.

Note: When type is not supported, text type creating simple text field will be used instead. That field will correctly recognize recommended values and display them to the user in a drop-down menu.

The recommended values in the range type will be shown as series of hash marks that the user can easily select.

The color type can show predefined colors in a browser-provided interface.

Password type

The specification allows linking <datalist> with a password type, but no browser supports it for security reasons.

Accessibility concerns

When deciding to use the <datalist> element, here are some accessibility issues to be mindful of:

• The font size of the data list's options does not zoom, always remaining the same size. The contents of the autosuggest do not grow or shrink when the rest of the contents are zoomed in or out.
• As targeting the list of options with CSS is very limited to non-existent, rendering can not be styled for high-contrast mode.
• Some screen reader/browser combinations, including NVDA and Firefox, do not announce the contents of the autosuggest popup.

Technical summary

Specifications, browser compatibility.

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

• The <input> element, and more specifically its list attribute;
• The <option> element.

• Latest Articles
• Top Articles
• Posting/Update Guidelines
• Article Help Forum

• View Unanswered Questions
• View All Questions
• View C# questions
• View C++ questions
• View Javascript questions
• View Visual Basic questions
• View Python questions
• CodeProject.AI Server
• All Message Boards...
• Running a Business
• Sales / Marketing
• Collaboration / Beta Testing
• Work Issues
• Design and Architecture
• Artificial Intelligence
• Internet of Things
• ATL / WTL / STL
• Managed C++/CLI
• Objective-C and Swift
• System Admin
• Hosting and Servers
• Linux Programming
• .NET (Core and Framework)
• Visual Basic
• Web Development
• Site Bugs / Suggestions
• Spam and Abuse Watch
• Competitions
• The Insider Newsletter
• The Daily Build Newsletter
• Newsletter archive
• CodeProject Stuff
• Most Valuable Professionals
• The Lounge  
• The CodeProject Blog
• Where I Am: Member Photos
• The Insider News
• The Weird & The Wonderful
• What is 'CodeProject'?
• General FAQ
• Ask a Question
• Bugs and Suggestions

HTML5 Datalists: What They Are and When to Use Them

This article is for our sponsors at CodeProject. These articles are intended to provide you with information on products and services that we consider useful and of value to developers

Autocompletion is a pattern that all Web users are familiar with. When you do a search, your search engine suggests terms. When you type a new e-mail message, your mail client suggest recipients. This functionality, however, has not been available to Web developers without a nontrivial amount of JavaScript. One of the new HTML5 elements, the <datalist>, brings this autocomplete functionality to the Web natively.

In this article, I'll describe what datalists are, when it's appropriate to use them, their limitations and what to do for browsers that don't support them. Let's get started.

Creating Datalists

To show how a datalist works, let's start with a traditional text input:

This field asks a user to provide his or her favorite sports team. By default, the user will be given no additional help to complete the field. But by using a datalist, you can provide a list of options the user can select from to complete the field. To do this, define a datalist with an option element for each suggestion:

To tie a datalist to an input element, give the input element a list attribute and the datalist an id attribute that match. Here’s an example:

Notice that the list attribute of the input and the id attribute of the datalist contain the same value, "team_list". This provides the link between the two.

That's it. No JavaScript is required to make a datalist work. Figure 1 shows what the user will see in supporting browsers after typing a D .

Note: Internet Explorer 10 and Opera do not require the user to type a character before seeing suggestions, whereas Firefox and Chrome do.

Option elements can also have a value attribute. This is useful when a user might not know the code associated with a given option. Consider the following U.S. state input:

Here, the user will see a list of full state names, but when the user makes a selection, the text input will be filled with the state's code rather than the full name. An example is shown in Figure 2 .

The autocomplete Attribute

If the datalists in Figure 1 and Figure 2 look familiar, it's because browsers have had autocompletion implemented for a long time. All browsers have some mechanism of storing a user's inputs to be used for autocompletion later.

Authors can use the autocomplete attribute to control whether the browser should attempt to automatically complete the user's data. The possible values are shown in the following example:

So what's the difference between the autocomplete attribute and datalists? The autocomplete attribute tells the browser whether to give a user options for completion based on previous input and whether to store the entered value for future completion. Datalists are author-provided lists of suggestions that are always displayed regardless of previous input.

One caveat is that setting the autocomplete attribute to "off" prevents datalists from displaying in Opera. Here’s an example:

Other Input Types

While autocompletion is traditionally associated with textual input, datalists can also be used on a number of the new HTML5 input types. Consider the range input type, which allows for the creation of a slider form element. By combining this with a datalist, you can suggest points on the range to the user.

For example, the following input asks the user to provide a donation between $5 and $200 dollars.

Figure 3 and Figure 4 show the display of a range input in Chrome 24 and Internet Explorer 10, respectively.

You can see that each browser displays a tick mark for each datalist option provided. Additionally, Chrome will snap the slider to these predefined values as the user moves the slider near them.

Unfortunately, Internet Explorer and Chrome are the only browsers to support datalists on range inputs at this time. Figure 5 shows support of datalists on common input types in modern browsers.

When to Use a Datalist

Since datalists have no built-in mechanism to require that a user select a provided option, they are well suited for inputs that can accept any value. The earlier example of providing a sports team fits here. While the datalist suggested teams, the user was free to input any value.

Conversely, the U.S. state example fails this test because there is a limited set of valid values that the user must provide. Such a use case is better handled by the select element because it forces a selection.

One exception to this is inputs with a large number of valid selections. For example, consider the traditional country drop-down list shown in Figure 6 .

This list impedes users by forcing them to sift through hundreds of options to find the one they're looking for. An autocomplete feature fits this use case well because a user can quickly filter the list by typing one or two characters.

Here’s how country selection can be implemented with a datalist:

Figure 7 shows what the user will see after typing a U.

Enforcing a Value

While datalists do not natively allow you to require that an option be selected, you can easily add validation that does so. For example, the following code makes use of the HTML5 constraint validation API to add such validation:

The constraint validation API is implemented in all browsers that support datalists, so if the datalist works, the validation should work as well. Now, when the user attempts to submit a form with an input that has a datalist (and they have not selected an option), they will see the error shown in Figure 8 .

It's important to note that the constraint validation API does not remove the need for server-side validation. Users working with older browsers will not have the constraint validation API available, and malicious users can easily subvert client-side scripts.

While this approach works in modern browsers, it presents an unusable UI to users running browsers that lack support. Users are told that they must select a valid value, but if their browser doesn't support datalists, they cannot see the options. Therefore, if you plan on using this approach, it's essential to provide a UI that works in all browsers. This can be accomplished by detecting whether the browser supports datalists and then polyfilling appropriately.

Unsupporting Browsers

At the time of this writing, datalists for text inputs are supported in Internet Explorer 10, Firefox 4+, Chrome 20+, and Opera, which unfortunately leaves out a large number of users.

Unlike with many new HTML5 features, for most use cases, no extra work needs to be done in browsers that do not support datalists. By default, the list of options you provide are merely suggestions; therefore, users with browsers that lack support will simply need to fill in the text field without any suggestions.

However, some fallback options can be used to provide a fuller experience to users running unsupporting browsers.

Fallback to Alternate HTML Content

One option, popularized by Jeremy Keith , is to take advantage of the fact that browsers that do not support the datalist element will still display child elements to the user. The following shows how the country datalist example can be altered and fallback to using <select>:

The UI presented to users in browsers that support datalists will not change, but users working with browsers without support now see a select element with the country options and a text box they can use to enter any value. This is shown in Figure 9 .

Polyfilling

One feature the select fallback doesn’t provide is the autocomplete behavior that datalists offer natively. If that is important for the datalists you’re adding, a second fallback option is to polyfill a datalist implementation.

To start, you first need to determine whether the user's browser supports datalists. The popular feature detection library Modernizr provides such a test, as shown here:

Using this approach, you can now polyfill a datalist implementation for users in unsupporting browsers. While several polyfills are available for datalists, I prefer using jQuery UI's autocomplete widget. The following code shows a polyfill implementation:

Figure 10 shows the display of the country list example in Safari with the jQuery UI autocomplete polyfill.

You may have noticed that by default, jQuery UI's autocomplete widget matches characters anywhere in the options, whereas datalists match options only at the beginning of the string. Unlike the native datalist, the autocomplete widget allows you to customize this to match options however you'd like.

The following example shows how you can build an autocomplete feature that matches options only at the beginning of the string:

Older Versions of Internet Explorer

To make any polyfill of the datalist element work in older versions of Internet Explorer, you need to take two extra steps.

Option Elements

The first is that Internet Explorer version 9 and earlier all require that option elements be immediate children of select elements. If they are not, these versions do not recognize them, and they will not be visible to the polyfill.

Luckily, this is easy to work around. By using conditional comments , you can place a select element around the options only for these versions of Internet Explorer. Refer to this example:

Internet Explorer version 9 and earlier will now detect the options appropriately. Internet Explorer 10 will not be affected since conditional comments were removed from the parser in Internet Explorer 10 . All other browsers will also ignore the comments.

In Internet Explorer version 8 and earlier, unknown elements cannot contain children. Therefore, even if a datalist's option elements are within select elements, they will still not be recognized.

Fortunately, there's an easy fix for this issue as well. The popular HTML5 Shiv library allows elements unknown to Internet Explorer 6–8 to have children. This shiv is included by default in Modernizr; just be sure the "html5shiv" check box is selected when you configure your download.

Limitations of Datalists

Although datalists are perfect for adding suggestions to text inputs, they suffer from a lack of customization capabilities that many modern Web applications require. For example, you cannot do the following with datalists:

• Use CSS to change its display or the display of its options.
• Control the positioning of the list.
• Control the number of characters typed before the browser displays results to the user.
• Control what is considered a match (case sensitivity, match at beginning of string vs. anywhere, and so on).
• Tie the input to a server-side datasource.

This means that if you need any of this functionality, you need to look into a more robust autocomplete solution. The jQuery UI autocomplete widget provides the ability to do all of this and more. The autocomplete widget also supports all browsers back to Internet Explorer 7 without the need of a polyfill. For more information on the autocomplete widget, check out its demos and API documentation . (The autocomplete widget handles only text-based inputs, therefore it won't be able to help you for some of the more specialized input types like range and color.)

Wrapping Up

Datalists provide a quick, native means of displaying input suggestions to the user. Since the options are merely suggestions, for many situations it's not necessary to provide a fallback for unsupporting browsers; users of these browsers simply will not see the suggestions.

For situations when you do want to provide a functional datalist to all users, you can detect support and polyfill the functionality for browsers that lack support.

While datalists are great for offering suggestions, they are limited in the functionality they provide. If you need a more robust autocomplete solution, jQuery UI's autocomplete widget is a good place to get started.

This article is part of the HTML5 tech series from the Internet Explorer team. Try-out the concepts in this article with 3 months of free BrowserStack cross-browser testing @ http://modern.IE .

About the Author

TJ VanToll is a Web developer and jQuery UI team member. He lives in Lansing, Michigan, and writes about his experiences with jQuery, HTML 5, CSS and other things that strike his fancy on his blog . He is the proud father of twin sons, and when he’s not on the Internet, he’s usually found chasing them in circles. Find TJ on his Blog and on Twitter- @tjvantoll .

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Comments and Discussions

Please enable JavaScript in your browser to enjoy a better experience.

A Look into: HTML5 Datalist

You probably have experienced this kind of response somewhere on the Web: when you are typing in an input form, a list of suggestions appears at the bottom of the input.

Over the years, we rely on JavaScript to create such a function. Today, we are able to do that with the new HTML5 <datalist> element. This HTML5 new element allows us to store a list of options that will be shown as the users type in the input.

A Look into: HTML5 Placeholder Attribute

One of my favorite new pieces in HTML5 is the ability to add Placeholder Text easily. The placeholder... Read more

HTML5 List Attribute

The <datalist> can be linked to <input> element using a new HTML5 attribute, list . We can use list in a few input types like text and search . But, according to Mozilla Developer Network , the list attribute is not applicable within the following input types: hidden , checkbox , radio , file and button .

In the following example, we add a list of cities with <datalist> and assign it with ID attribute, like so.

To hook the <datalist> to an <input> element, simply add list attribute and refer to the id attribute, like so.

Browser Behavior

Each browsers that support <datalist> element, Chrome, Opera and Firefox act slightly different.

In Chrome , it will show the options that start with the value we type in. In the example below, Chrome shows values that start with “s” .

On the other hand, as we click on the input twice , it will show all the options available, as shown below.

In Opera , as we are focusing on the input form, it immediately shows all the options and then sort them based on the initial letters we type in.

Firefox will not show anything upon focusing in the input. It will show the options that contain the values as we type them in. For example, this screenshot below shows Firefox displaying the options that contain the letter “u” .

Safari at the moment, does not support the <datalist> element and Internet Explorer is reported to support this element as of version 10.

Using HTML5 Datalist with Polyfills

There are a few polyfills to replicate similar functionality in unsupported browsers. In this post, we will implement the datalist polyfills from Michael Taylor. To use it, we will need jQuery and Modernizr for browser feature detection.

As for the Modernizr, we have to make a few customizations. In the Modernizr download page , check the following options.

• Input Attributes under the HTML5 section
• Modernizr.addTest under the Extensibility section
• Modernizr.load under the Extra section
• elem-datalist under the Non-core detects

Now, let’s open the HTML document where we add the <datalist> element and add the Modernizr library we have just downloaded in the <head> section.

After adding Modernizr, we can test the browser whether it supports datalist element with the script below.

The script above will show an alert saying “This browser does not support HTML5 datalist element, so we will load the polyfills” when datalist element is not supported. In Safari, it looks like this.

Next, create a new JavaScript file named load.datalist.js and add this line below in it. This will target and run the script to the input that has the list attribute.

Lastly, we will load the jQuery, jquery.datalist.js and load.datalist.js using Modernizr.load , as follows.

Thus, they will be loaded only when the browser does not support <datalist> element.

That’s it, now you can view the demo in action or download the source file from the links below.

• Download Source

Further Resources

Below are a few resources to dig into this subject further.

• HTML5 Datalist Element, Predefined options for other controls – W3.org
• HTML5 Datalist – David Walsh
• Example of a dynamic HTML5 datalist control – Raymond Camden

HTML References

Html <datalist> tag.

A datalist with pre-defined options (connected to an <input> element):

Definition and Usage

The <datalist> tag specifies a list of pre-defined options for an <input> element.

The <datalist> tag is used to provide an "autocomplete" feature for <input> elements. Users will see a drop-down list of pre-defined options as they input data.

The <datalist> element's id attribute must be equal to the <input> element's list attribute (this binds them together).

Browser Support

The numbers in the table specify the first browser version that fully supports the element.

Global Attributes

The <datalist> tag also supports the Global Attributes in HTML .

Event Attributes

The <datalist> tag also supports the Event Attributes in HTML .

Related Pages

HTML DOM reference: Datalist Object

Default CSS Settings

Most browsers will display the <datalist> element with the following default values:

COLOR PICKER

Contact Sales

If you want to use W3Schools services as an educational institution, team or enterprise, send us an e-mail: [email protected]

Report Error

If you want to report an error, or if you want to make a suggestion, send us an e-mail: [email protected]

Top Tutorials

Top references, top examples, get certified.

Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others!  Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

datalist html5 safari

Is there a possible workaround for the datalist tag? My requirement is to implement a search text bar using a text input field in combination with a drop down on my website

Posted on Jan 5, 2017 1:14 AM

Loading page content

Page content loaded

Jan 5, 2017 6:32 AM in response to aroragarima

Hello aroragarima,

Just implement it the same way you would have done before the data tag ever existed. As new features are added to HTML, it will take a long time before they are useable across browsers.

Here is a polyfill ( https://github.com/thgreasi/datalist-polyfill ). That is just the first github result from Google. There are probably a dozen more.

Jan 19, 2017 4:08 AM in response to aroragarima

Please post your question here.

https://discussions.apple.com/community/developer_forums

May 7, 2017 4:34 PM in response to aroragarima

And here's an ever better polypill:

https://github.com/mfranzke/datalist-polypill

• Main Content

• JavaScript Promises
• ES6 Features

HTML5 Datalist

One of the most used JavaScript widgets over the past decade has been the text box autocomplete widget.  Every JavaScript framework has their own autocomplete widget and many of them have become quite advanced.  Much like the placeholder attribute 's introduction to markup, a frequently used functionality has been moved from a JavaScript-only utility to HTML via the new DATALIST element.

A DATALIST element gets an ID attribute and contains numerous OPTION elements, just as a SELECT element would:

Once the DATALIST element is in place, a list attribute gets added to an INPUT element which refers to the list ID :

What's provided is a very rudimentary but useful autocomplete list of existing items that match given text.  Of course the lack of styling that comes with OPTION elements isn't optimal, and there's no method to hook DATALIST 's up to a service endpoint for more dynamic suggestions, but this new element is a step in the right direction!

Recent Features

Responsive Images: The Ultimate Guide

Chances are that any Web designers using our Ghostlab browser testing app, which allows seamless testing across all devices simultaneously, will have worked with responsive design in some shape or form. And as today's websites and devices become ever more varied, a plethora of responsive images...

How to Create a RetroPie on Raspberry Pi – Graphical Guide

Today we get to play amazing games on our super powered game consoles, PCs, VR headsets, and even mobile devices.  While I enjoy playing new games these days, I do long for the retro gaming systems I had when I was a kid: the original Nintendo...

Incredible Demos

Introducing MooTools ScrollSidebar

How many times are you putting together a HTML navigation block or utility block of elements that you wish could be seen everywhere on a page? I've created a solution that will seamlessly allow you to do so: ScrollSidebar. ScrollSidebar allows you...

MooTools: Set Style Per Media

I'd bet one of the most used MooTools methods is the setStyle() method, which allows you to set CSS style declarations for an element. One of the limitations of MooTools' setStyle() method is that it sets the specific style for all medias.

Alas, non-functional on Android JB default browser.

That’s a renderer issue, not a standards issue.

Is there anyway, I can query my database for results.

Nope, you’ll need to output the list upon page load. You could, I suppose, do an ajax query and inject/remove elements from the list.

Doesn’t work in Safari 6.0.2 ? Works in Chrome and FF.

“Renderer issue” with Safari on iOS 6.0.1 / iPod Touch as well. :-(

Sorry, genius here typed select in angle brackets…message should have read:

I love datalists but really wish the option sub-elements worked like they do in a i.e. had the ability to display a label whilst having a different (hidden to the end user) value. That’d be so nice, then you could replace big horrible s with datalists.

I know there are some tasty libs like http://harvesthq.github.com/chosen/ but native options are always handy to have available.

p.s. I realise setting value and label on datalist option elements sort of works but you get the value displayed on the popup which is messy in most cases.

I like the new datalist concept but I’m struggling to understand the best way to use it. My difficulty is that if you know all the acceptable inputs why not use another html form element like: a drop down box if space is tight or check/radio boxes?

I particularly like drop down boxes because the user doesn’t have to worry about typing the correct input (typos) and you help the user by reducing the amount of keystrokes they need to use to complete your form.

But there must be a good application and I’ve love to hear some ideas…

I guess datalist should be styled invisible for old browsers?

This… this is phenomenal. Thank you for sharing!

This will cut my development time drastically because I use autocomplete on many different pages of an internal web application and I decide what browsers the sales people (85% of the company) use.

I’ll for sure install Chrome for them and save the company time and money by using this HTML5 feature.

Doesn’t seem to work on Chrome for Android. It’s a step in the right direction but needs ajax support to be really useful.

I have the same issue with this as Virendra and Dennis. If the data volume is small enough to be rendered as a datalist, I don’t see any point in using an autocomplete over a standard select box. The main use-case for autocomplete is for searching in large-volume datasets, where a regular select box becomes unusable.

Good work in Mozilla v.17 :)

If I am not mistaken, the advantage this has over a select box is that the select box restricts the user to the finite list of options available, whilst an input with a datalist suggest values, but allows the user to input a value not in that list.

So maybe more “auto-suggest” than “auto-complete” :-)

I cannot see why would this be desired addition to HTML. There are too many things that you’d want to customise to make it useful, e.g. debouncing, ability to query data endpoint, ability to do partial search are just a few of top of my head. The task is hardly trivial to accomplish using JavaScript.

It is my opinion, that the same way that placeholder introduction encouraged bad UX practises and cross-browser incompatible UIs, the datalists will become another thing on the “progressive enhancement” list.

I don’t see why you would add some AJAX to the standards. It’s just as easy to listen for a type event on the input and occupy the datalist with new options.

Nice solution! :)

Hi, I am a web developer working for IBM’s Eclipse Orion( http://www.eclipse.org/orion/ ) team. We used to use HTML5 data list but as it is not supported in Safari and IE(9 at the moment), we implemented our own. The data binding is customize-able and the suggestion list is fully style-able. You can also put categories there. I have a blog post describing how to use it and there is js-fiddle demo link where you can try to change the data provider and the style. Give it a try and feed back please.

Sorry, I forgot to put my blog llink in the last comment: http://libing-wang.blogspot.com/2012/10/the-search-input-completion-in-eclipse.html

Nice :) The complaints about browsers / engines not supporting it is moot. You could always progressively enhance with javascript and that’s (imo) the way to go anyway. Better take the standards as a starting point than stay behind forever. Keep ‘m up!

The future is bright!

I have to agree with the comments above regarding using this with AJAX. It’s simple enough to do a call with javascript/jQuery and populate the list based on that.

Adding AJAX calling to the standard is removing the separation between your front end and back end code, which I don’t think would be a good direction to head in.

how cani retrive databse tables values in datalist tag. plz any one give me source code for tht..

@dennis It is useful for changing fields like “town” but rarely do you know all towns that will be put… but those that already exist you want the user to see as soon as typing begins.

I’m wondering if it is possible to show datalist suggestions only by clicking on the input field?

Double click the Input box. It will roll down the list with the data.

Hi. Is it possible to limit the input to what’s in the datalist only ?

imagine if we have 100,000 records! does it a good idea?

how about 1,000,000 records? could be work speedy? i think so it will be heavy for large records! hum?!

Adding hundred thousand records in the list is not a good idea. It might slow down the process. However, you can filter the records by dynamically adding data to the Datalist. See the example here. http://bit.ly/1AXqI1q Its only problem is Styling and matching a character randomly in the list of values.

Nothing stops you from combining the datalist with Ajax. Let the user start typing, and fill in the datalist dynamically.

E.g. if you have a name input formular, initially fill the datalist with the most common forenames. Either autocompletion kicks in (which, in the case of mobile devices e.g. might even be integrated into the virtual keyboard application!!) or the user tries to type something the initial data list didn’t include.

While the user types, replace the content of the datalist with more appropriate suggestions.

The big benefit over all these proprietary solutions is a much better integration with the native look&feel of the users environment, e.g. none of these is capable of providing data to the mentioned virtual keyboards.

As with many other HTML5 tags, datalists are not intended as a replacement for JS enhanced gimmicks, but rather as a semantic bridge between application logic and the native UI of the users environment.

don’t see any point in using an autocomplete over a standard select box. I’ll for sure install Chrome for them and save the company time and money by using this HTML5 feature.

How can i change background-color after selection? Emergency, please!

Hi! I have tried to make a search hint table using datalist, but I have any idea to show or open datalist recomendations/hints after adding this to the datalist. There are any class o pseudo class for the datalist to show it

Whoops. I love but datalist does anyone know if browsers intend to optgroup support ?

Hello. I want to select more then one inputs from the data list.The second input should be placed next to the first input. Just like when we enter few letters to add the email recipient it autocompletes it and then we can add few more recipients to the same list to send emails. Can we do that in HTML? Thanks & regards! Excuse any typo’s.

Hello. I want to select more then one inputs from the data list.The second input should be placed next to the first input. Just like when we enter few letters to add the email recipient it autocompletes it and then we can add few more recipients to the same list to send emails. Can we do that in HTML? Thanks & regards! Excuse any typo’s.

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!

When HTML is not enough: a tale of the <datalist> element

• web development

HTML 5.0 was finalized in 2014 (and its drafts were published even earlier), and with it came the <datalist> element. It’s 2020, and even though it might look like a good replacement for custom autocomplete widgets, browser issues made me get rid of it.

I’ve built a web app to help me track my expenses. The app is written in Django, and it’s open source . One of the goals was to have a simple codebase with limited external JS dependencies, as well as basic usability with JS disabled. This is partially to facilitate learning of standard DOM manipulation routines and TypeScript.

The JS/TS bits are called the Scripting Enhancements to reflect their nature. The biggest items are an interactive bill editor (a table with add/edit/remove operations, that submits its data as a regular HTML POST <form> ) and an autocomplete framework (used by the bill editor in an advanced way, and by other screens in the app with a more basic featureset). The autocomplete framework is exactly what you’d expect: point it at an input field and a URL, and keypresses lead to the URL being queried for previous values for this field, which are displayed as possible values to the user to save typing.

Autocomplete with HTML 5: the <datalist> tag

But how to display the options to the user? Most people would display a position: absolute box with links/buttons, throw in some more logic around the focus and blur events, and call it a day. There are tons of ready-made solutions that do all that for you, although most of them are terrible. But! HTML 5 introduced a <datalist> tag. And it looks like everything you could need. You link a <datalist> tag to an <input> and it shows matching options in an autocomplete-style box. In fact, here’s a simple demo, in case your browser supports it:

Now, here are a few takeaways from that demo:

Options are displayed in the same order as in the <datalist> tag in the source, this list was sorted reverse-alphabetically in the source, and that’s how it appears in the source.

The list is filtered case-insensitively based on user-input substrings. In Chrome, Firefox and Safari, the substring can appear at any point in the string. But in Edge (old Microsoft engine), it looks only at the beginning of the string.

Some browsers show an arrow on the field to show the entries, sometimes double-clicking opens the list.

The entry for C# is as follows: <option value="C#">C Sharp</option> . Chrome displays it on as “ C# C Sharp ” (on two lines), Safari shows only “C#”, Firefox and Edge show “C Sharp”. Selecting the option always inputs C#.

Mobile Safari does not expand the list by default, but displays some of the options above the keyboard (as typing predictions). You can click on the arrow to display all the options in a scrolling picker .

Chrome on Android displays it the same way as on desktop (drop-down list).

This demo uses static, hardcoded data. Doing that for the Expenses app would be terrible for performance — that would waste bandwidth, force the browser to parse a fairly long list, and it could easily overload the browser when it tries to expand the list. But wiring it up to a fetch() call to a REST API should not be hard, and browsers work correctly when the datalist changes.

An emoji hack

One of the features I needed was to make the auto-complete fill out more than one field at once. Well, <datalist> has no specific support for that. It only supports showing a list and putting the value in the input box it’s connected to. But choosing something from the list fires the usual input event. I opted to do this: show every entry with a sparkles emoji (✨) in front, with the two other fields also inside this string, delimited by other emoji, and then catch the input event. If the field beigns with ✨, then use a regex to go from one emoji-delimited string to three, and place the correct strings in three input boxes (while also removing the sparkles from the first field).

Yes, it’s a hack. But it’s pretty okay appearance-wise, and it does work. It wouldn’t have worked so well in Edge, but I didn’t even know about this behavior before writing this blog post, and the initial sparkles emoji could be dropped and I could still make it work.

Works on mobile? Yes, except…

I went on and deployed the <datalist> -based autocomplete to my site. It looked good, worked fine. To use the thing on mobile, I’ve got a special launcher app. Its main reason for existence? I want a home screen icon, but Chrome only allows progressive web apps to do that (and that’s busywork I don’t feel like doing), and back then, Firefox (which has no such restrictions) did not support <datalist> on Android. The app is fairly simple, with a standard WebView widget and a slide-out navigation drawer, and a few other nice things, and it’s 120 SLOC of Kotlin.

But then, I bought a new phone, and with it, upgraded from Android 7 to 9. And I hit a bug in Chrome, which is still not fixed. The bug? HTML datalist doesn’t work on Android 8 or higher in WebView .

Oh. We’ve got a bit of a problem. Firefox still didn’t seem to support <datalist> . But there’s one more way to make an app show a webpage: Custom Tabs. This is a feature you’ve probably seen around Android, and it’s somewhere in between. The app gets minimum control over the appearance of the toolbar, but the “real” web browser is responsible for rendering the page. Chrome in a Custom Tab supports <datalist> . So I built a small app to do what I wanted.

There was just one minor thing to fix. My default browser on mobile is Firefox Focus . The main features of Focus are tracking protection, content blocking, and storing zero history and cookies (permanent incognito mode with one-click clearing). This is perfect for clicking random links, especially since I hate Chrome’s insistence on showing webpages you visited 5 years ago once when autocompleting URLs. (Chrome is my secondary browser on mobile; on desktop, I almost always have an incognito window open.)

Why is Focus relevant to this story? One, it (still) does not support the tag. Two, the default browser is also the provider of the Custom Tabs. Which is great for my web-browsing habits, but won’t solve the problem. Fortunately, it’s just a one-line change to send the intent directly to Chrome. The entire thing is less than 30 lines long. You can see the full CustomTabsActivity.java file, but the relevant bits are below.

It seems to work well, the list is displayed, and it can be used to input stuff, the emoji hack works too.

There was one more bug with Chrome on Android. Typing a character sometimes led to it appearing twice: I typed A , the hints appeared, then the text box started showing AA , and my hints disappeared. I can’t reproduce it right now, but that also made the entire flow just annoying.

With all the browser bugs, support issues, and various glitches, I decided to build an autocomplete widget of my own. I took the CSS from Bootstrap 4, and used Popper.js to do the positioning. It looks and works better, has keyboard support, and is definitely less hacky (the emoji is still there, because they look good, but my entries know the original object they were made from and can just tell the handler to use that instead of using regex). And it beats many of the autocomplete widgets out there, because they often fail when you hold the mouse a bit longer; also, it can reposition itself to the top if there’s more space. All that in just 198 SLOC of TypeScript. (I also discovered a bug in my code that made it work a bit worse, fixing it for the old implementation would still not fix the other issues.)

What’s the moral of the story? Even though HTML 5 has been a standard for many years, browser support for the new tags still seems to be an issue. And sometimes, it’s better to just put in the extra work and build a good UI on your own, instead of trusting the browser to do it right.

The same applies to other “new” HTML 5 form elements. <input type="date"> is not supported in desktop Safari, and is fairly ugly in desktop Firefox and Chrome. It displays the standard OS picker on mobile, which gets you a calendar on Android, but a scrolling picker on iOS. datetime-local is currently Chrome-only. month lets you click on a day and end up with an entire month selected in Chrome. A custom component with JavaScript would be far more consistent and often easier to use.

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Minimal and dependency-free vanilla JavaScript polyfill for the awesome datalist-functionality

mfranzke/datalist-polyfill

Folders and files, repository files navigation, datalist-polyfill.

Update: Safari now supports the datalist element at least basically, as announced earlier in 2019 with the latest release of Safari both for iOS and MacOS X . Yeah !!! Exciting news! I'm planning to release a new major version soon to both cheer as well as accommodate their implementation.

This is a minimal and dependency-free vanilla JavaScript polyfill for the awesome datalist-functionality, that will bring joy and happiness into our lives :-)

• supports all standard's functionality as well as mimics other browsers behavior.
• mitigating the different levels of support both by Safari and IE9+ as well as Edge
• Released under the MIT license
• Made in Germany. And supported by so many great people from all over this planet - see "Credits" accordingly.
• Compatible down to Microsoft Internet Explorer 9
• Lightweight (see the badge above)
• Fully flexible to change the datalist entries / <option> s
• the relevant input field types: text , email , number , search , tel and url ...
• ... while leaving the others like color or date related, as those would most likely need another polyfill to work correctly or have a meaningful UI
• input[type=email] elements multiple attribute
• properties .options for datalist elements and .list for input elements
• right to left text-direction
• non-touch and touch interactions
• different types of option declarations
• both Safari and Internet Explorer (IE9+) browsers
• controlling the display of differing value and label values
• on input[type=url] omitting the scheme part and performing intelligent matching on the domain name
• substring matching on both the value and the text values
• Emits "input" event when item in the datalist is selected
• up and down arrow keys
• pressing printable characters
• Implements the WAI-ARIA design pattern

Core concepts

The polyfill was designed with the following concepts kept in mind:

• dependency-free
• Supporting DOM changes by event delegation and MutationObserver
• code accessibility / readability

Installation

Just integrate the JavaScript file into your code - et voilà.

You may optionally load via NPM or Bower:

Nothing really, just plug it in, it will should work out of the box.

This package is also enabling the .options (for datalist elements) and .list (for input elements) properties according to the specs.

If you set a title -Attribute on the <datalist> HTML tag, it would get used as label for the first disabled entry within the polyfilling select on non-touch interactions.

dynamic HTML (or DHTML, if you like to be a little bit nostalgic)

In case that you'd like to dynamically add or modify / create your HTML code, you're good to go with this polyfill, as it's based on event delegation and additionally using MutationObserver (IE11+) that makes your UI work easily - no refresh nor reinit function to call after DOM manipulation or something similar.

Changes to the available option elements

If you'd like to make a change to the integrated list of <option> elements, feel free to either remove or add them right away - the list would get generated on the fly after the user typed in something into the <input> field, so you're covered on this.

You can also disable <option> elements by adding the disabled attribute to the <option> HTML tag if necessary.

Differing value and label values

As the browser vendors (Google Chrome vs. the others) don't seem to be aligned on this topic, I've decided to enable the label -attribute to serve as the definitive label being displayed, even if a value is being defined differing from the label. On different value and text values, both of them would get displayed within the suggestions, as Google Chrome does it. But if you define a differing label -attribute, its value would get displayed exclusively (as all the other browsers do it) to give you some flexibility on how to define those suggestions. Check out the „Different ways of defining an option“ section on the demo page regarding this topic.

value property on the option elements for Microsoft IE 10 & IE 11 and Edge

As explained in detail below in the section "Microsoft Internet Explorer 10 & 11 and Microsoft Edge" , for fixing missing behaviour in IE 10+ and Edge we're manipulating the value for the option elements in those browser so you can't access them securely as a getter, but would need to take the original values out of data-originalvalue .

Microsoft Internet Explorer

Microsoft edge.

Microsoft Edge doesn't trigger the input event any more after selecting an item via mouseclick (on input elements other than type of text ), even though that IE11 still did, nevermind ...

That for the optimizations on substring matching for Microsoft Edge specifically by #GH-39 (as explained further in the following "Microsoft Internet Explorer 10 & 11 and Microsoft Edge" section) need to get restricted to input[type="text"] elements even only.

There might be possible solutions to even also achieve the expected behaviour on non-text-input elements - even though that I only could think about ugly solutions that I don't want to have within the polyfill and that might even also break existing CSS & JS architecture / selectors.

Microsoft Internet Explorer 10 & 11 and Microsoft Edge

As mentioned with #GH-63, related to aspects reported via #GH-36 and #GH-39 (and in Microsoft Edges platform issues ), it doesn't work in IE 10 & 11 as well as in Edge to "Search both the value and label, using substring matching; currently it searches both the value and label, but uses prefix matching".

As requested with #GH-36 we wanted to even also enrich the experience within the "newest" IE versions (10 & 11) and Edge browsers that provided basic support, but not the substring matching for users input. In this case the technical solution has been to manipulate the values in a way that the browser could actually handle that functionality as well, by including the users input at the beginning of the value after a substring matching to the original value, followed by a unique string for preventing any inconsistencies, followed by the original value itself, in this case for the sorting of the entries (this is mainly done in the updateIEOptions function around line 191 to 200 of the code).

This actually leads to a different behavior for the developers on the value property of each option elements within the datalist element for IE & Edge, but on the other hand provides a better UX for IE & Edge users by a consistent behavior for the user.

Microsoft Internet Explorer 9

You'll need the declaration for the standard hidden attribute, that you might already have included in case you're using normalize.css . Otherwise just adapt it from there:

And you need to add a nesting select element wrapped by a conditional comment into the datalist element. Please have a look at the demo page accordingly, the code is being listed at the beginning.

See the polyfill in action either by downloading / forking this repo and have a look at demos/index.html and demos/ie9/index.html , or at the hosted demo: https://mfranzke.github.io/datalist-polyfill/demos/ and https://mfranzke.github.io/datalist-polyfill/demos/ie9/

things to keep in mind

• The HTML demo code is meant to be simple - I do know that things like a surrounding <form> are missing, and I've left the latin letters and english expressions for the right to left text-direction example. But lets focus on the relevant tags that this polyfill is all about for the demo.
• iOS Safari handles the label -attribute different from Safari on Mac OS. This is being equalized during the handling of the label -attributes-value for differing value and label values.
• As I wanted to mainly focus on native elements in the most low level / simple way instead of visually emulating a list and than afterwards regain all of the functionality via a lot of JavaScript logic, I've ended up with this element, that knows how to play nicely with nested <option> elements.
• I tried its multiple attribute, as this is most likely already what you're up to regarding appearance, but it does violate the form-follows-function concept and results in - surprise - the possibility for multiple selections, which isn't always <datalist> elements kind of thing... Then the size attribute came to my attention, which much better fits the requirements and behaves as designed quite perfectly.
• Let the datalist element be a direct follower of the input element - and don't nest it into the label in case that you're doing so with the input (which you nevertheless shouldn't do in general, but hey, gods great zoo is great).
• If embedding a webview within an iOS app, you should be using WKWebView instead of UIWebView , as it supports datalist right natively and the latter even also leads to a JavaScript error (thanks to @jscho13 for mentioning this).

Supported by Christian, Johannes, @mitchhentges, @mertenhanisch, @ailintom, @Kravimir, @mischah, @hryamzik, @ottoville, @IceCreamYou, @wlekin, @eddr, @beebee1987, @mricherzhagen, @acespace90, @damien-git, @nexces, @Sora2455, @jscho13, @alexirion and @vinyfc93. Thank you very much for that, highly appreciated !

Tested with

• macOS 10.13, Safari 11
• macOS 10.12, Safari 10
• macOS 10.11, Safari 9
• iPhone 8 Simulator, Mobile Safari 11.0
• iPhone 7 Plus Simulator, Mobile Safari 10.0
• iPad Pro Simulator, Mobile Safari 9.3
• Windows 7 SP1, Internet Explorer 9.0.8112.16421
• Windows 8.1, Internet Explorer 11.0.9600.19101

Cross-browser testing platform provided by CrossBrowserTesting

Prospects & functionality overview

The following problems are mainly reported and listed on caniuse as well as due to issues flagged on Github.

Personally I even also do like the "keep it simple" approach provided within the W3C specs even already.

But on the other hand this leads to an additional visible field, but doesn't emulate the (hopefully, fingers crossed) upcoming x-browser implementation and leaves unnecessary syntax for all of the clients that wouldn't even need it (anymore).

If you're trying out and using my work, feel free to contact me and give me any feedback. I'm curious about how it's gonna be used.

And if you do like this polyfill, please consider even also having a look at the other polyfill we've developed: https://github.com/mfranzke/loading-attribute-polyfill

Contributors

Code contributors.

Financial Contributors

Become a financial contributor and help us sustain our community. [ Contribute ]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [ Contribute ]

Code of conduct

Sponsor this project, contributors 18.

• JavaScript 99.6%

THE 5 BEST Moscow Safaris

Safaris in moscow.

• Adrenaline & Extreme Tours
• Gear Rentals
• Nature & Wildlife Tours
• 5.0 of 5 bubbles
• District Central (TsAO)
• 3rd Transport Ring (TTK)
• District North-Eastern (SVAO)
• District Eastern (VAO)
• District South-Western (YuZAO)
• Lomonosovskiy
• Ostankinskiy
• Meshchanskiy
• Krasnoselskiy
• Maryina Roshcha (Jewish Quarter)
• Good for Couples
• Good for Kids
• Good for Big Groups
• Adventurous
• Budget-friendly
• Good for a Rainy Day
• Hidden Gems
• Honeymoon spot
• Good for Adrenaline Seekers
• Things to do ranked using Tripadvisor data including reviews, ratings, photos, and popularity.

1. Rybokhotsoyuz

2. Easy Russia Tour Guide

3. UTS GROUP

4. 365AltaiMongolia

5. #1 Russia -Tanzania | Zanzibar, Serengeti Safari & Kilimanjaro Agency | BURIGI CHATO SAFARIS CO LTD

6. Aviashop.Ru

7. Transsib Moscow

8. BASK TOUR

• Easy Russia Tour Guide
• #1 Russia -Tanzania | Zanzibar, Serengeti Safari & Kilimanjaro Agency | BURIGI CHATO SAFARIS CO LTD
• 365AltaiMongolia