HTML forms may be mundane but they’re essential for the majority of web sites and apps. In HTML4, input fields were limited to:
input type="hidden"— for data the user cannot view
input type="file"— for uploads
textarea— for longer text entry
select— for drop-down lists
button— generally used for submitting a form, although
input type="image"could also be used.
- CSS styling possibilities were limited,
- custom controls such as date and color pickers had to be developed in code, and
Additional HTML5 Input Types
A deluge of new
|enter an email address|
||enter a telephone number — no strict syntax is enforced but line breaks will be removed|
||enter a URL|
||a search field with line breaks automatically removed|
||a floating point number|
||a control for entering an approximate value, typically represented by a slider|
||enter the day, month and year|
||enter the day, month, year, hour, minute, second and microsecond based on the current UTC timezone|
||enter a date and time with no timezone|
||enter the month and year with no timezone|
||enter a week number with no timezone|
||enter the time with no timezone|
||specify a color|
Unless stated otherwise, input fields can have any of the following form-specific attributes. Several are Boolean attributes, that is, they do not require values, e.g
<input type="email" name="email" required />
although you can add them if you prefer a stricter XHTML-like syntax, e.g.
<input type="email" name="email" required="required" />
||the input field name|
||an initial value|
||the maximum length of the entered string. This can also be applied to
||the minimum length of the entered string. This is documented but, at the time of writing, browser support is poor and the attribute causes HTML validators to error. An alternative option is
||a subtle text hint shown in the input box|
||set focus to this (non-hidden) field when the page loads|
||indicates that a value must be entered|
||ensures a value adheres to a regular expression|
||the minimum value permitted (numeric and date types)|
||the maximum value permitted (numeric and date types)|
||the value granularity. For example,
||provides the browser with a hint for auto-completion, e.g. “billing email” or can be set to “on” or “off” to enable and disable accordingly|
||specifies the input mechanism. The most useful options:
||the size in characters for
||number of text rows (
||number of text columns (
||points to a set datalist options|
||set to true or false to enable or disable spell checking|
||the ID of the form which this input belongs to. In general, inputs should be nested inside a
||specifies a URI to override the
||specifies GET or POST to override the
||specifies the type of content when submitting (
||specifies a target window/frame to override the
||the input value cannot be changed although it will be validated and submitted|
||disables the input — no validation will occur and data will not be submitted|
date fields must always use YYYY-MM-DD for
The following example requests a mandatory email which ends in @mysite.com and has focus when the page loads:
<input type="email" name="login" pattern="@mysite\.com$" autocomplete="email" autofocus required />
A datalist contains a set of suitable options for any type of
<input type="text" name="browser" list="browsers" /> <datalist id="browsers"> <option value="Chrome" /> <option value="Firefox" /> <option value="Internet Explorer" /> <option value="Safari" /> <option value="Opera" /> </datalist>
datalist is supported, the browser presents auto-complete options when you start to type. The whole list is usually shown if you double-click the control or click the down arrow (if shown). Unlike a standard
select drop-down, the user is free to override these choices and enter their own value.
It’s possible to set values and text like standard select options, e.g.
<option value="IE">Internet Explorer</option>
but be aware that implementations differ. For example, Firefox auto-completes on the text itself (Internet Explorer) while Chrome prefers the value (IE) and shows the text greyed out:
Validation for the whole form can be disabled by setting a
novalidate attribute on the
form element. Alternatively, you can set a
formnovalidate attribute on the form’s submit button/image.
Remember also that setting an input’s
disabled attribute will prevent validation on that field.
While we’re primarily discussing input types, HTML5 also provides read-only output options:
output— the result of a calculation or user action
progress— a progress bar (the
maxattributes define the status)
meter— a scale which can change between green, amber and red depending on the values set for the attributes
Separating and Labeling Inputs
The whatwg.org form specification states:
Each part of a form is considered a paragraph, and is typically separated from other parts using <p> elements
Interesting. I normally use a
div although I doubt it matters from a semantic perspective. A
p tag is shorter although it’s possible you’ll need to apply a class to modify margins.
More importantly, you should use label elements either around or next to the input itself with a
for attribute stating the input’s ID, e.g.
<p> <p> <label for="firstname">First name</label> <input type="text" id="firstname" name="firstname" placeholder="first name" required maxlength="20" /> </p> <p> <label for="lastname">Last name</label> <input type="text" id="lastname" name="lastname" placeholder="last name" required maxlength="20" /> </p> <p> <label for="email">Email address</label> <input type="email" id="email" name="email" placeholder="firstname.lastname@example.org" required maxlength="50" /> </p> <p> <label> <input type="checkbox" name="newsletter" /> Sign up for our newsletter </label> </p>
No Standard Controls
There are no specific interface guidelines for browser vendors to follow. This is intentional: a typical desktop mouse-controlled date picker can be too small on a mobile device so the vendor can implement a touch-based alternative.
Not every input type and attribute is supported in all browsers. In general, most modern browsers from IE10+ include basics such as email and number. However, the date types are only supported in Webkit and Blink browsers at the time of writing.
The browser will revert to a standard
text input when a specific type and ignore attributes when those values are not supported.
Always Use the Correct Type!
It’s important to use the correct input type for the data you’re requesting. That may seem obvious but you will encounter situations when you’ll be tempted to use a standard text input.
Consider dates. Support is patchy and this leads to implementation issues:
- The standard
dateinput always returns dates in YYYY-MM-DD format regardless of how the date picker is presented in your locale.
- IE and Firefox will fall back to a standard
textinput, but your users may expect to enter values in US MM-DD-YYYY or European DD-MM-YYYY format.
The easy solution is to abandon the HTML5
date input, revert to
Browser validation is not guaranteed. Even if you forced everyone to access using the latest version of Chrome you could never prevent:
- the user changing your HTML or scripts using browser tools
- submission from systems outside your control, or
- data interception between the browser and the server (certainly over HTTP).
Client-side validation never has and never will be a substitute for server-side validation. Validating user data on the server is essential. On the client, it’s a nice-to-have.
Finally, remember dates may be received in YYYY-MM-DD or whichever format you specified to the user (MM-DD-YYYY, DD-MM-YYYY, etc.) Check for digits in the first four characters or use native language/framework date parsing methods as necessary.
We’ve covered a lot in this article. In the next part we’ll look at form-related CSS properties.
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.