The following is an extract from our book, HTML5 & CSS3 for the Real World, 2nd Edition, written by Alexis Goldstein, Louis Lazaris, and Estelle Weyl. Copies are sold in stores worldwide, or you can buy it in ebook form here.
You can find Part 1 here.
Numbers
The number
type (type="number"
) provides an input for entering a number. Usually, this is a spinner box, where you can either enter a number, or click on the up/down arrows in a native browser spinner UI to select a number.
Let’s change our quantity field to use the number
input type:
<label for="quantity">I would like to receive <input type="number"
↵min="1" name="quantity" id="quantity"> copies of
<cite>The HTML5 ↵ Herald</cite></label>
Figure 4.8 shows what this looks like in Opera.
On many touchscreen devices, focusing on a number
input type will bring up a number touch pad (rather than a full keyboard).
The number
input has min
,
max
, and step
attributes to specify the minimum, maximum, and incremental values allowed. If the step
is omitted it defaults to 1
.
If you would like to allow float values, you must specify a float step, such as 0.1 or the keyword any
to allow for any value. Note that some browsers will minimize the width of the number form field for restricted numbers. For example, min="0" max="10" step="1"
doesn’t need to be as wide as step="any"
, where the user could enter the full value of Pi.
Warning: Use number
with Caution
There will be times when you may think you want to use
number
, when in reality another input type is
more appropriate. For example, it might seem to make sense that a
street address should be a number. But think about it: would you
want to click the spinner box all the way up to 34154? More
importantly, many street numbers have non-numeric portions: think
24½ or 36B, neither of which work with the number
input type.
Additionally, account numbers may be a mixture of letters and numbers, or have dashes. If you know the pattern of your number, use the pattern
attribute. Just remember not to use number
if the range is extensive or the number could contain non-numeric characters and the field is required. If the field is optional, you might want to use number
anyway, or tel
in order to prompt the number or telephone keyboard as the default on touchscreen devices.
Ranges
The range
input type (type="range"
) displays a slider control. As with the number type, it allows the min
, max
, and step
attributes. The difference between number
and range
, according to the spec, is that the exact value of the number is unimportant with range
. It’s ideal for inputs where you want an imprecise number; for example, a customer satisfaction survey asking clients to rate aspects of the service they received.
Let’s change our registration form to use the range
input type. We’ll create a field asking users to rate their knowledge of HTML5 on a scale of 1 to 10:
<label for="rating">On a scale of 1 to 10, my knowledge of HTML5
↵is:</label>
<input name="rating" type="range" min="1" max="10" step="1">
Figure 4.9 shows what this input type looks like in Safari. In this case the step
attribute is not required, as it defaults to 1
. A negative value for step
will break the range by making the thumb immovable in Firefox.
The default value of a range is the midpoint of the slider—in other words, halfway between the minimum and the maximum. Including the list
attribute with an associated datalist
enables creating little notches along the slider path showing the location of the suggested values.
The spec allows for a reversed slider (with values from right to left) if the maximum specified is less than the minimum; however, no browsers currently support this. Additionally, the spec allows for two thumbs with the inclusion of the multiple
attribute. No browsers support this either.
range
is supported in all browsers, starting with Firefox 23, Android 4.2, and Internet Explorer 10. list
support on the range
input type is currently only found in Chrome 20+, Opera, and Internet Explorer 10+.
Colors
The color
input type (type="color"
) provides the user with a color picker—or at least it does in some browsers, including BlackBerry 10, Firefox 29+, Safari 8+ for desktop, Chrome, Opera, and Android 4.4. WebKit for iOS 8 and Internet Explorer 11 are yet to support the color
input type. The color picker returns a lower-case hexadecimal RGB color value, such as #ff3300
, with the default value being #000000
(black).
If you want to use a color input, provide placeholder text indicating that a hexadecimal RGB color format is required, and use the pattern
attribute to restrict the entry to only valid hexadecimal color values.
We don’t use color in our form, but if we did, it would look a little like this:
<label for="clr">Color: </label>
<input id="clr" name="clr" type="color" placeholder="#ffffff"
↵pattern="#(?:[0-9A-Fa-f]{6})">
The resulting color picker is shown in Figure 4.10. Clicking the Other… button brings up a full color wheel, allowing the user to select any hexadecimal color value. If you’re after other colors, use the list
attribute with an associated datalist
to define each color you want to suggest as individual options. This is currently supported in Blink browsers only.
Dates and Times
There are new date and time input types, some of which are included in the HTML5 specification, as well as a few others that are still listed in the HTML Living Standard and the HTML5.1 draft that may be at risk. The date
and time
input types made it into the HTML5 W3C Recommendation, while datetime
, datetime-local
, month
, and week
are at risk of being dropped. All date and time inputs accept data formatted according to the ISO 8601 standard.
Here are the available date and time input types:
date
: comprises the date (year, month, and day), but no time; for example, 2004-06-24.time
: signifies a time of day using the military format (24-hour clock); for example, 22:00 instead of 10.00 p.m.month
: only includes the year and month; for example, 2012-12.week
: covers the year and week number (from 1 to 52); for example, 2011-W01 or 2012-W52.datetime
: includes both the date and time, separated by a “T”, and followed by either a “Z” to represent UTC (Coordinated Universal Time) or by a time zone specified with a + or – character; for example, “2011-03-17T10:45-5:00” represents 10:45 a.m. on the 17th of March, 2011 in the UTC minus five hours time zone (Eastern Standard Time). This value has been removed from the spec and then added back in. It is currently without support.datetime-local
: is identical to datetime, except that it omits the time zone; the main difference is that datetime-local is supported in browsers that support date and time, while datetime is not.
The most commonly used of these types is date
. The specifications call for the browser to display date controls. At the time of writing, WebKit for iOS, Chrome 20+, and Opera provide calendar controls for most of these values. Internet Explorer 11, Safari for desktop, and Firefox 37 still do not.
Let’s change our subscription start date field to use the date
input type:
<label for="startdate">Please start my subscription on:</label>
<input type="date" min="1904-03-17" max="1904-05-17"
↵id="startdate" name="startdate" required aria-required="true"
↵placeholder="1904-03-17">
Now, we’ll have a calendar control when we view our form in Opera, Chrome, or iOS WebKit, as shown in Figure 4.11. Unfortunately, it’s unable to be styled with CSS at present.
For the month
and week
types, browsers display a similar UI as the date input type, but only allow the user to select full months or weeks. In those cases, individual days are unable to be selected; instead, clicking on a day selects the whole month or week. While datetime-local
is supported in these browsers, datetime
is not. datetime
has been deprecated. month
, week
, and
datetime-local
are at risk as well, but have yet to
fall to the same fate. Chrome lost support for datetime
in version 26, Opera in version 15, and Safari in iOS7. Instead of using datetime
since support should be deprecated, use date
and time
as two separate input types.
We recommend including a minimum and maximum when using the date
input type. As with number
and range
, this is done with the min
and max
attributes.
The placeholder
attribute that we added to our start date field earlier is made redundant in browsers supporting the datepicker interface, but it makes sense to leave it in place to guide users of IE, Safari, and Firefox until they implement the date and time controls. Until all browsers support the UI of the new input types, placeholders are a good way to hint to your users what kind of data is
expected in those fields. Remember, they’ll just look like regular text fields in nonsupporting browsers.
Tip: Dynamic Dates
In our example, we hardcoded the min
and max
values into our HTML. If you wanted the minimum to be the day after the current date—which makes sense for a newspaper subscription start date—this would require updating the HTML every day. The best way to handle it is to dynamically generate the minimum and maximum allowed dates on the server side. A little PHP can go a long way:
<?php function daysFromNow($days){
$added = ($days * 24 * 3600) + time();
return date("Y-m-d", $added);
}
?>
In our markup where we had static dates, we now dynamically create them with the above function:
<li>
<label for="startdate">Please start my subscription on:
↵</label>
<input type="date" min="<?php
echo(daysFromNow(1)); ?>"
↵max="<?php echo(daysFromNow(91)); ?>"
id="startdate"
↵name="startdate" required aria-required="true"
↵placeholder="<?php echo(daysFromNow(1)); ?>">
</li>
This way, the user is limited to entering dates that make sense in the context of the form.
You can also include the step
attribute with these input types. For example, step="7"
on date
will limit the user to selecting only one day per week: the particular weekday depends on the min
if one is present, or is the current day of the week if none is present. On time
input, the step
attribute must be expressed in seconds, so adding step="900"
on the time
input type will cause the input to step in increments of 15 minutes.
Alexis Goldstein first taught herself HTML while a high school student in the mid-1990s, and went on to get her degree in Computer Science from Columbia University. She runs her own software development and training company, aut faciam LLC. Before striking out on her own, Alexis spent seven years in Technology on Wall Street, where she worked in both the cash equity and equity derivative spaces at three major firms, and learned to love daily code reviews. She is a teacher and a co-organizer of Girl Develop It, and a very proud member of the NYC Resistor hackerspace in Brooklyn, NY.
Estelle Weyl is a front-end engineer from San Francisco who has been developing standards-based accessible websites since 1999. She also writes two technical blogs with millions of visitors. Her passion is teaching web development so you'll find her speaking about CSS3, HTML5, JavaScript, and mobile web development at conferences around the United States.
Louis is a front-end developer, writer, and author who has been involved in the web dev industry since 2000. He blogs at Impressive Webs and curates Web Tools Weekly, a newsletter for front-end developers with a focus on tools.