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 default type for input elements is "text".

All browsers ignore unknown attributes.

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.

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.

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:

Browser

Supported?

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.

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:

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:

Browser

Supported?

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.

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.

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:

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.

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.

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:

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:

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.

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:

Browser

Supported?

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".

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.

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:

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.