The Modern Web

Before moving on to discuss more input types, I want to make a brief digression to talk about some of the many new attributes. These attributes bring some useful and crucial new properties and behavior to HTML forms and, once again, are based on popular script libraries and workarounds created by developers and made official as part of HTML5.

The autofocus attribute, which is common to all input types, simply sets the focus on the specified element when the page is loaded. In a text input field, for example, the cursor would already be placed and ready for the user’s input. autofocus is a Boolean attribute, so the value to activate it can be either autofocus or just left out entirely, as shown here:

If multiple instances of autofocus are used on a page, the first (in DOM order) will be respected.

Keep in mind that some users, especially those requiring assistive technology, may be confused by being automatically focused on a form when the page loads. Check out Bruce Lawson’s article “The Accessibility of HTML5 Autofocus” for a discussion of best practice (see Appendix I).

The placeholder attribute, which you can use on any text-like input element (the ones I’ve already introduced in this chapter, for example), takes a string of characters as its value; this string will be displayed inside the input when no value is present. Use the string for instructions on the type of value required; for example, in an email input you might include something like this:

The placeholder text should not describe the value of the input—for example, “Work email”—as that’s the role of the label element. Remember the placeholder text disappears when users click in the box, so they may not remember what field they’re filling out if the label isn’t present.

Most browsers style the placeholder text lighter than the default color to show that it’s holding text rather than a value, but depending on your website’s color scheme that may not be ideal. Unfortunately, no standardized selector is available to change placeholder text properties, although some browsers have implemented their own proprietary pseudo-class (or pseudo-element):

The autocomplete attribute sets whether the browser should remember previous values entered into a field and offer them back to you in the future. The values are on and off; the default is on, but if you’re creating a site with confidential form information, you may want to set this to off to increase the user’s security by not offering suggestions to someone who may subsequently use the same device:

Many browsers now offer native spellchecking facilities. These are usually applied, by default, to textarea elements only, but you can apply the spell-checker—if present—to any field by using the spellcheck attribute. This is a slightly strange attribute, as it’s Boolean but doesn’t behave like the other attributes of that type; it requires a value of true or false to enable or disable spellchecking:

By default, the dictionary used will be in the language of the user’s browser, but you can change this with the lang attribute. If the user has the stated language dictionary installed (Spanish, in the following example), that dictionary will be used for spellchecking:

The multiple attribute is for situations when the user can enter or submit more than one entry in a field. You can pair it with the file input to select multiple files from a user’s device or with the email input to enter more than one email address in the field. The attribute is a true Boolean, so only the attribute name is required:

One of the limitations of forms in HTML 4.01 was that all form elements, including the submit button, had to be contained within the form element itself, meaning that, unless JavaScript were used, all the elements had to follow each other subsequently in the markup, limiting the ways they could be laid out on the page.

HTML5 has addressed this with the form attribute, which takes as a value the id of a form element, creating an association between the field and the form regardless of their position in the markup. The value of the element is then submitted along with the form. In this example, the input #bar will be submitted along with the form #foo:

You can find a great introduction to SVG at the SVG Basics website: http://www.svgbasics.com/, and the W3C’s own SVG Primer is a useful way to dig deeper: http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html. MDN has a quite complete list of elements and attributes: https://developer.mozilla.org/en-US/docs/SVG/.

The technique for stacking SVG icons was developed by Erik Dahlström and is described on the blog of Simurai: http://simurai.com/post/20251013889/svg-stacks/. Mozilla’s Robert O’Callahan warns of the possible changes to the stacking technique: http://robert.ocallahan.org/2012/10/impending-doom-for-svg-stacks-sort-of.html. I detailed the svgView() method on my blog, Broken Links: http://www.broken-links.com/2012/08/14/better-svg-sprites-with-fragment-identifiers/.

The IE Testdrive site has a good hands-on tool for experimenting with SVG Filter Effects: http://ie.microsoft.com/testdrive/graphics/hands-on-css3/hands-on_svg-filter-effects.htm.

Dirk Schulze wrote a good, concise introduction to the features planned for SVG2: http://dschulze.com/blog/articles/8/new-features-in-svg2/.

You can find a good range of canvas tutorials, from beginner to expert level, at http://www.html5canvastutorials.com/, and an excellent cheat sheet with all of the core properties and methods on Jacob Seidelin’s blog at http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html (last updated in 2009 but still relevant).

HTML5 Rocks has a tutorial on making more advanced image manipulation effects at http://www.html5rocks.com/en/tutorials/canvas/imagefilters/.

In his blog post “Building a Live Green Screen with getUserMedia() and MediaStreams,” Tim Taubert explains the basics of live video image manipulalation: http://timtaubert.de/blog/2012/10/building-a-live-green-screen-with-getusermedia-and-mediastreams/.

The Learning WebGL blog has lessons for complete beginners on working in a three-dimensional context in canvas at http://learningwebgl.com/lessons/, and WebGL.com has frequent roundups of demos, tutorials, and developer meet-ups: http://www.webgl.com/.

jQuery Notes

jQuery has a companion called jQuery Mobile, which might at first sound like a mobile-optimized version of the library, but it’s not that simple; jQuery Mobile is actually an extension to jQuery that provides cross-platform widgets and styles, as well as new events and methods that take advantage of the new capabilities provided by mobile devices. It requires the jQuery library to run, meaning extra weight is added to your pages.

If you need a lightweight mobile-optimized library, you may want to consider an alternative such as Zepto.js, which features a jQuery-compatible API but is only 25 percent of its size. jQTouch is a library that provides many of the same features as jQuery Mobile but weighs in much lighter and is compatible with both jQuery and Zepto, although its browser support may not be as broad as that of jQuery Mobile. I advise you to evaluate each fully to find which one is best suited to your purposes.

Many browsers, especially Chrome and Firefox, are being much more cautious than they used to be with regard to implementing experimental features. Where previously they would implement features with a vendor prefix and roll them out to all users, now they usually require that you explicitly enable certain features with a configuration flag.

In Firefox, you do this by entering about:config in the URL bar, at which point you’ll see a message that warns you of the consequences of dabbling in the browser’s inner workings. If this doesn’t deter you, you can find the feature you want and enable it before restarting your browser in order to gain access to the now-enabled feature.

In Chrome, the process is much the same except that you enter chrome://flags, no warning message appears, and the features are usually enabled by toggling a link marked Enable.

A new range of CSS pseudo-classes, known as the UI element states pseudo-classes, augments the extra functionality provided to forms by HTML5. These pseudo-classes let you style form elements based on their current interaction or validation state. The names of the pseudo-classes are really quite descriptive, and I imagine their meanings are clear to you, but just in case you’ve had a hard day and aren’t thinking straight, I’ll briefly explain them.

Form fields that are required (that is, have the required attribute set to true) can be styled with the :required pseudo-class, the opposite of which is :optional. You could, for example, give a dark border to required fields and a lighter border to optional ones:

The :valid and :invalid selectors are applied to elements based on their current validation state; :valid is used to apply styles to a valid form field, and :invalid to an invalid form field. That being the case, you may want to style the text of each input element in a different color based on its state: green for valid and red for invalid:

input:valid { color: green; }

input:invalid { color: red; }

Where elements accept text input—such as text, url, or search—you can provide a list of helpful suggestions to the user. The browser can offer these based on the user’s previous input (controlled by the previously mentioned autocomplete attribute), but at times you may want to suggest a range of predefined terms. Implement this latter option with the datalist element.

The datalist element contains a list of suggestions, each of which is contained in an option child element (which you should be familiar with from the select element in HTML 4.01). To illustrate what I mean, here’s a short datalist with only a few options:

The datalist element isn’t rendered on the page and doesn’t have to be close to the input that refers to it; it can be placed anywhere in the markup.

To create an association between the input field into which the user will enter data and the datalist element that holds the suggestions, the former uses the id value of the latter as the value for its own list attribute:

This association between the id and list attributes means that multiple inputs can refer to the same datalist element, if required.

In browsers that don’t support datalist, the input box falls back to a standard text input. Please keep this in mind if you require certain input values from the user, and ensure you have contingencies in JavaScript and on the server side.

Before I explain how you can use SVG in your pages, I want to run briefly through the code behind it. You see, SVG is actually an XML file that marks up the image that it creates; this means you can view it in a text editor and change it manually—something that is basically impossible with bitmap files.

Open an SVG file in your preferred editor, or view the source in a browser window, and inspect the contents. Although the actual markup varies wildly from file to file, you will at least be able to see the many common elements. To begin, all SVG files start with the XML declaration, which holds the version number of XML you’re using, the text encoding method, and the standalone attribute that sets whether the file makes reference to other external files or stands alone (in most cases, just leave this as no):