In June 2013, Coreservlets.com will be hosting a live HTML5 training course in Maryland, developed and taught by David Geary. David is the author of Core HTML5 Canvas (as well as eight best-selling Java texts), is a three-time Java Rock Star at Java One, and has spoken and taught all over the world.

New HTML5 Input Types and Attributes

HTML5 defines a variety of new input types: sliders, number spinners, popup calendars, color choosers, autocompleting suggest boxes, and more. The beauty of these elements is that you can use them now: for browsers that don't support a particular input type, there is automatic fallback to standard textfields. There are two keys to understanding why the automatic fallback works consistently in all major browsers:

The consequence of these two points is that if you say <input type="foo" bar="baz"/>, all browsers will treat this identically to <input type="text"/> (unless "foo" is a recognized input type or "bar" is a recognized attribute of the input element). For each of the new input types, we present a high-level description, an overview of the syntax, a description of the main attributes, a summary of which current browsers support it, and an example you can experiment with in your browser. Please send corrections and suggested improvements to hall@coreservlets.com.

Overview

For each of the new input types, we present a tabbed panel similar to the following.

A high-level description of what this input type does (in browsers that support it).
A summary of the syntax for this input type in HTML5.
The main element-specific attributes used by this input type (if any).
A summary of which browsers support this feature. As of January 2013, Opera had the most complete support for these new input elements, followed closely by Chrome. Firefox and Safari had moderate support, and Internet Explorer had no support at all. For each type of input element, we use the modernizr.com code to detect if your browser supports it. You are currently using .
The first sample (HTML5) uses the new input type. Try using it to enter data of proper and improper types and see what you get in your browser. The second sample (Pre-HTML5) is simply <input type="text"/>, so you can compare the look and behavior of the two versions. If your browser does not support this element type, then the two versions should look and act exactly the same.

<input type="number"/> (Spinner)

This input type lets you collect a number (either integer or floating point). All known browsers that support this use a spinner.









<input type="number" min="0" max="20" step="2" value="10" name="some-name"/>
You should normally supply all of value, min, and max. Browsers that support this input type give inconsistent behavior when these attributes are omitted. If you want to collect floating point numbers, use a non-integer for min or step.
  • value: The initial value. If omitted, the field is initially blank, but the internal value is not consistent across browsers.
  • step: How much to change the value when you click on the up or down arrows of the control. The default is 1.
  • min, max: The smallest and largest values that can be selected with the up/down arrows. However, Chrome lets you type values outside that range directly into the textfield, and then gives no error when you submit. Opera also lets you type values outside the range, but gives an error when you try to submit. However, the Opera error message incorrectly refers to the maximum value, so is of little use in the current version. See the Browser Support section for an Opera screen shot.
I tested number input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 No Same as ordinary textfield:
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Yes
Safari 5.1.7 Yes
Opera 12.12 build 1707 Yes
Of the five tested browsers, Opera is the only one that gives an error message when you directly type in a too-small or too-large value, then try to submit the form.



<input type="number"/>
HTML5
Choose number:
Pre-HTML5
Choose number:

<input type="number" min="0" max="20" step="2" value="10"/>
HTML5
Choose even number (0-20):
Pre-HTML5
Choose even number (0-20):

<input type="range"/> (Slider)

This input type lets you collect a number (either integer or floating point). All known browsers that support this use a slider. The exact value is not displayed to the user unless you use JavaScript. So, use the number (spinner) input type if you want to let the user choose an exact value. Browsers are supposed to use a horizontal slider unless you attach CSS that specifies a smaller width than height, in which case they are supposed to use a vertical slider.









<input type="range" name="some-name"/>
Unlike with the number (spinner) input type, the range (slider) input type has reasonable defaults for min, max, step, and value. If you want to collect floating point numbers, use a non-integer for min or step.
  • value: The initial value. The default is halfway between the min and the max.
  • step: How much to change the value when you click on the up or down arrows of the control. The default is 1.
  • min, max: The smallest and largest values that can be selected. The default for min is 0, and the the default for max is 100.
I tested range input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 No Same as ordinary textfield:
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Yes
Safari 5.1.7 Yes
Opera 12.12 build 1707 Yes



<input type="range"/>
HTML5
Choose number:
Pre-HTML5
Choose number:

<input type="range" min="0" max="200" step="10" value="50"/>
HTML5
Choose number (0-200):
Pre-HTML5
Choose number (0-200):

<input type="date"/> (Popup Calendar)

This input type lets you collect a date. Chrome and Opera use a textfield with a calendar that pops up when you clieck in the textfield, and it is expected that this is what most future browsers will do. Safari uses an interface that looks like a number spinner but increments the yyyy-mm-dd string one day at a time. As of January 2013, neither Firefox nor Internet Explorer has any support at all for date input. There are also closely related elements to let you select a month (input type="month"), week (input type="week"), time (input type="time"), date and time in global format (input type="datetime"), and date and time in local format/timezone (input type="datetime-local"). Note that the modernizr.com library incorrectly reports that the latest version of Safari (5.1.7) does not support date input, when in fact it does (albeit with a much poorer interface than Chrome and Opera).









<input type="date" name="some-name"/>
In Opera and other future browsers that pop up calendars, the calendar selection defaults to the current date. So, all of value, step, min, and max can be omitted. However, in the current version of Chrome, selecting the up/down arrows starts at 0001-01-01 unless you supply a value. The Chrome behavior is unhelpful, since you will need JavaScript to calculate the current date at run time. Also, if you have two related date input fields (e.g., start date and end date), you might want to use JavaScript to change the second field when the first field changes (e.g., set the end date to one day after the start date).
  • value: The initial value. The format is "yyyy-mm-dd".
  • step: The step size in days. The default is 1.
  • min, max: The smallest and largest dates that can be selected, formatted as date strings of the form "yyyy-mm-dd".
I tested date input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 No Same as ordinary textfield:
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Yes This is the version where I supplied an initial value:
Safari 5.1.7 Yes, but with poor interface. Hopefully, future Chrome versions will use a popup calendar. Same as ordinary textfield:
Opera 12.12 build 1707 Yes



<input type="date"/>
HTML5
Choose date:
Pre-HTML5
Choose date:

<input type="date" value="2011-06-01"/>
HTML5
Choose date:
Pre-HTML5
Choose date:

<input type="color"/> (Color Chooser)

This input type lets you collect a color of the form #rrggbb. If a browser supports this input type, the intention is that clicking in the textfield will result in a color chooser popping up.









<input type="color" name="some-name"/>
  • value: The initial value. The intention is that if a browser pops up a color chooser, the initial selection will match the current value.
I tested range input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 No Same as ordinary textfield:
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Yes Shows a colored area, that when pressed, pops up a color picker:
Safari 5.1.7 No Same as ordinary textfield:
Opera 12.12 build 1707 Yes
If you click on "Other", you get an more detailed color chooser:

If your browser supports color input, clicking in the top entry should result in a color chooser popping up. Otherwise, the HTML5 and Pre-HTML5 entries should look and behave identically.

<input type="color"/>
HTML5
Choose color:
Pre-HTML5
Choose color:

<input type="..." list="some-id"/> (Autocomplete/Suggest Box)

Adding the "list" attribute lets you add autocomplete behavior to most of the text-oriented input types (reqular textfields, email, URL, search, etc.) covered in this tutorial. The value of "list" should be the id of a "datalist" element that contains "option" elements giving the choices.

Note that the new (and poorly named) HTML5 "autocomplete" attribute is not used for these lists of choices, but instead is a flag that tells the browser whether or not it should used stored form values from previous sessions.

Sadly, the HTML5 autocompletion has no options for customizing the look, for using HTML in the autocomplete list, or for defining how the match against the choices is performed. So, if you are using JavaScript anyhow, the autocompleters from Scriptaculous, jQuery UI, Ext/JS, Dojo, etc., are far more usable.









<input type="text (or other)" list="some-id" name="some-name"/>
<datalist id="email-choices">
<option label="Display Val 1" value="Insert Val 1">
<option label="Display Val 2" value="Insert Val 2">
<option label="Display Val 3" value="Insert Val 3">
...
</datalist>

Note that non-HTML5 browsers will ignore the datalist and option elements, and in HTML5, closing tags are not required. So, you use <option ...>, not <option .../>.

The input element

  • list: The id of a separate "datalist" element that defines a list of choices for the user to choose among.

The option element (inside "datalist")

  • label: Extra information that may be displayed in the autocomplete list. Browsers might show this label or a combination of the label and the value. The label is never part of the value that is inserted into the textfield when the entry is selected.
  • value: The value that should be inserted into the textfield when the entry is selected.
I tested autocompletion (i.e., the "list" attribute) with vanilla textfields (input type="text") on the latest versions of the five most popular browsers on Windows. See later sections on email and URL input for support for autocomplete lists with those textfield types. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 Yes
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Yes
Safari 5.1.7 No Same as ordinary textfield:
Opera 12.12 build 1707 Yes



<input type="text" list="employee-id-choices"/>
HTML5
Choose Employee ID:
Pre-HTML5
Choose Employee ID:

<input type="email"/> (Email Entry)

This input type lets you collect an email address. If the "list" attribute is not specified, then the intention is that the browser supplies some help in entering a legal email address (e.g., the iPhone browser uses an email-optimized keyboard) and/or validation on submission. As of January 2013, the latest versions of Chrome and Safari claim to support email input, but have no difference in look or behavior. As of January 2013, the latest version of Opera has no difference in look on input, but performs email address validation on submission.

If the "list" attribute is specified, then the intention is that the browser lets the user choose among a set of email addresses defined separately with the "datalist" element.

<input type="email" name="some-name"/>
<input type="email" list="email-choices" name="some-name"/>
<datalist id="email-choices">
<option label="Marty Hall" value="hall@coreservlets.com">
<option label="Somebody Else" value="someone@example.com">
<option label="Third Person" value="other@example.com">
...
</datalist>
If you supply the "list" attribute, you must also supply a separate "datalist" entry.
  • value: The initial value (a legal email address).
  • list: The id of a separate "datalist" element that defines a list of email addresses for the user to choose among.
I tested email input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 Single: Yes, List: Yes Single on submission:

List on entry:
Internet Explorer 9.0.8112.16421 Single: No, List: No Same as ordinary textfield:
Chrome 23.0.1271.97 m Single: Yes, List: Yes. Single on submission:

List on entry:
Safari 5.1.7 Single: claims Yes, but no noticeable difference. List: No.
Opera 12.12 build 1707 Single: Yes, List: Yes Single on submission:

List on entry:



<input type="email"/>
HTML5
Enter email address:
Pre-HTML5
Enter email address:

<input type="email" list="email-choices"/>
HTML5
Choose email address:
Pre-HTML5
Choose email address:

<input type="url"/> (URL Entry)

This input type lets you collect an absolute URL. If the "list" attribute is not specified, then the intention is that the browser supplies some help in entering a legal URL (e.g., the iPhone browser uses a URL-optimized keyboard) and/or validation on submission. As of January 2013, the latest versions of Firefox and Chrome do good validation of the value on submission. Safari claims to support URL input, but has no difference in look or behavior. The latest version of Opera has no difference in look on input, but performs minor editing on change and validates illegal characters on submission. On change, Opera adds "http://" to the front of URLs that lack it. (The definition of onchange is when you enter something and then click in a different textfield or otherwise have the original textfield lose focus.) On submission, Opera gives an error message if the URL contains illegal characters, but does not do full URL validation (e.g., "http://blah" [no host] and "htp:" [bogus protocol, no host] are both allowed).

If the "list" attribute is specified, then the intention is that the browser lets the user choose among a set of URLs defined separately with the "datalist" element.









<input type="url" name="some-name"/>
<input type="url" list="url-choices" name="some-name"/>
<datalist id="url-choices">
<option label="HTML5 Spec" value="http://dev.w3.org/html5/spec/">
<option label="Some other URL" value="http://example.com/blah.html">
<option label="Yet Another URL" value="http://foo.bar.com/baz.html">
...
</datalist>
If you supply the "list" attribute, you must also supply a separate "datalist" entry.
  • value: The initial value, as an absolute URL.
  • list: The id of a separate "datalist" element that defines a list of URLs for the user to choose among.
I tested URL input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 Single: Yes, List: Yes
Internet Explorer 9.0.8112.16421 Single: No, List: No Same as ordinary textfield:
Chrome 23.0.1271.97 m Single: Yes, List: Yes.
Safari 5.1.7 Single: claims Yes, but no noticeable difference. List: No.
Opera 12.12 build 1707 Single: Yes (small editing on change), List: Yes (drop-down list of choices) Single, on change after entering "abc":

Single, on submission after entering "a b c":

List, on entry:



<input type="url"/>
HTML5
Enter URL:
Pre-HTML5
Enter URL:

<input type="url" list="url-choices"/>
HTML5
Choose URL:
Pre-HTML5
Choose URL:

<input type="tel"/> (Telephone Input)

This input type is intended to help you collect a telephone number. However, since the format of telephone numbers is not specified, it is not clear how a normal browser would help you with this. However, a cell phone might use an on-screen keyboard that is optimized for phone number input. As of January 2013, Firefox, Chrome, Safari, and Opera claim to support telephone input, but show no difference when entering values and perform no validation when submitting values.









<input type="tel" name="some-name"/>
  • value: The initial value as a phone number.
I tested telephone input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 No Same as ordinary textfield:
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Claims Yes, but no noticeable difference
Safari 5.1.7 Claims Yes, but no noticeable difference
Opera 12.12 build 1707 Claims Yes, but no noticeable difference



<input type="tel"/>
HTML5
Enter phone number:
Pre-HTML5
Enter phone number:

<input type="search"/> (Search Query Input)

This input type is intended to help you collect a string for a search. Since search queries are free-form text, there is never any help in inputting characters, and never any validation on submission. However, on some platforms, search fields should look slightly different than regular textfields (e.g., with rounded corners instead of with square corners). However, on Windows, as of January 2013, no tested browser showed any difference whatsoever, even when (as with Firefox, Chrome, Safari, and Opera) the browser claimed to support search input.









<input type="search" name="some-name"/>
  • value: The initial value.
I tested search input on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 Claims Yes, but no noticeable difference
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Claims Yes, but no noticeable difference
Safari 5.1.7 Claims Yes, but no noticeable difference
Opera 12.12 build 1707 Claims Yes, but no noticeable difference



<input type="search"/>
HTML5
Enter query:
Pre-HTML5
Enter query:

<input type="..." placeholder="some text"/> (Textfields with Temporary Hints)

Adding the "placeholder" attribute lets you add a hint inside the textfield, but where the hint automatically disappears when you click inside it. This is like the "Password" text inside the textfield in the Windows login window.









<input type="text (or other)" placeholder="some text" name="some-name"/>

The input element

  • placeholder: A small hint. This differs from the "value" attribute in two ways. First, it will usually be rendered differently (e.g., light gray). Second, it will automatically disappear when you click in the textfield.
  • value: The initial value. If you have both placeholder and value, the value wins, and placeholder is ignored.
I tested placeholder text with vanilla textfields (input type="text") on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 Yes
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Yes
Safari 5.1.7 Yes
Opera 12.12 build 1707 Yes



<input type="text" placeholder="1 letter + 4 nums"/>
HTML5
Enter Employee ID:
Pre-HTML5
Enter Employee ID:

<input type="text" placeholder="1 letter + 4 nums" value="a1234"/> The point here is that "placeholder" is ignored if you also have "value".
HTML5
Enter Employee ID:
Pre-HTML5
Enter Employee ID:

<input type="..." pattern="some regular expression"/> (Pattern-Validating Textfields)

Adding the "pattern" attribute lets you specify a regular expression (in JavaScript RegEx format) for legal values. This is particularly useful when the legal pattern is clear from the prompt, or when you use "placeholder" to describe the pattern. As of January 2013, Firefox, Chrome, and Opera give an error message on form submission when the value fails to match the pattern; however, the error message is pretty generic ("Please use the required format"), and thus does not give the user much help with how to correct the error. But, if you also add placeholder text or regular text telling the user what format to enter, this error message may be quite helpful. On attempted submission, Safari underlines bad values in red and blocks the submission.









<input type="text (or other)" pattern="some regexp" name="some-name"/>
  • pattern: A JavaScript regular expression.
I tested "pattern" with vanilla textfields (input type="text") on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 No Same as ordinary textfield:
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Claims Yes, but no noticeable difference
Safari 5.1.7 Claims Yes, but no noticeable difference
Opera 12.12 build 1707 Yes (generic error message on submission)



<input type="text" pattern="[a-z][0-9]{4}" placeholder="1 letter + 4 nums"/>
HTML5
Enter Employee ID:
Pre-HTML5
Enter Employee ID:

<input type="..." required/> (Textfields with Required [Non-Empty] Values)

Adding the "required" attribute lets you specify that the user must enter a value before submitting the form. As of January 2013, Firefox, Chrome, and Opera give an error message on attempted form submission when the textfield is empty. Safari claims to support "required", but in actuality do nothing with it.









<input type="text (or other)" required name="some-name"/>
  • required: A flag indicating that empty textfield values are illegal. HTML5 does not follow XML syntax, so it is perfectly legal to just do
    <input ... required .../>
    However, if you prefer to supply attribute values, you can do
    <input ... required="required" .../>
    However, "true" is not a legal value, so it is illegal to do
    <input ... required="true" .../>
I tested "required" with vanilla textfields (input type="text") on the latest versions of the five most popular browsers on Windows. Here are the results as of January 2013:
BrowserSupported?Appearance
Firefox 17.0.1 No Same as ordinary textfield:
Internet Explorer 9.0.8112.16421 No Same as ordinary textfield:
Chrome 23.0.1271.97 m Claims Yes, but no noticeable difference
Safari 5.1.7 Claims Yes, but no noticeable difference
Opera 12.12 build 1707 Yes (error message on submission)



<input type="text" required />
HTML5
Enter First Name (*):
Pre-HTML5
Enter First Name (*):

Tutorials and Training from coreservlets.com

In June 2013, Coreservlets.com will be hosting a live HTML5 training course in Maryland, developed and taught by David Geary. David is the author of Core HTML5 Canvas (as well as eight best-selling Java texts), is a three-time Java Rock Star at Java One, and has spoken and taught all over the world. Coreservlets.com also offers a variety of other Java- and Web-related training courses and free tutorials. Please see our public training course schedule or contact us for a quote on a customized training course taught onsite at your organization.