1. New Doctype
Still using that pesky, impossible-to-memorize XHTML doctype?
If so, why? Switch to the new HTML5 doctype. You’ll live longer — as Douglas Quaid might say.
In fact, did you know that it truthfully isn’t even truly necessary for HTML5? However, it’s used for current, and older browsers that require a specified doctype. Browsers that do not accept to this doctype will conveniently render the contained markup in standards mode. So, without difficulty, feel forgive to toss scold to the wind, and hug the adding HTML5 doctype.
2. The Figure Element
Consider the following mark-up for an image:
There unfortunately isn’t any easy or semantic way to associate the caption, wrapped in a paragraph tag, with the image element itself. HTML5 rectifies this, with the introduction of the
<figure> element. When combined with the
<figcaption> element, we can now semantically associate captions with their image counterparts.
3. <small> Redefined
Not long ago, I utilized the
<small> element to create subheadings that are closely related to the logo. It’s a useful presentational element; however, now, that would be an incorrect usage. The
small element has been redefined, more appropriately, to refer to small print. Imagine a copyright statement in the footer of your site; according to the new HTML5 definition of this element; the
<small> would be the correct wrapper for this information.
small element now refers to “small print.”
4. No More
Types for Scripts and Links
You possibly still add the
type attribute to your
This is no longer necessary. It’s implied that both of these tags refer to stylesheets and scripts, respectively. As such, we can remove the
type attribute all together.
5. To Quote or Not to Quote.
…That is the question. Remember, HTML5 is not XHTML. You don’t have to wrap your attributes in quotation marks if you don’t want to you. You don’t have to close your elements. With that said, there’s nothing wrong with doing so, if it makes you feel more comfortable. I find that this is true for myself.
Make up your own mind on this one. If you prefer a more structured document, by all means, stick with the quotes.
6. Make your Content Editable
The new browsers have a nifty new attribute that can be applied to elements, called
contenteditable. As the name implies, this allows the user to edit any of the text contained within the element, including its children. There are a variety of uses for something like this, including an app as simple as a to-do list, which also takes advantage of local storage.
Or, as we learned in the previous tip, we could write it as:
7. Email Inputs
If we apply a
type of “email” to form inputs, we can instruct the browser to only allow strings that conform to a valid email address structure. That’s right; built-in form validation will soon be here! We can’t 100% rely on this just yet, for obvious reasons. In older browsers that do not understand this “email” type, they’ll simply fall back to a regular textbox.
At this time, we cannot depend on browser validation. A server/client side solution must still be implemented.
It should also be noted that all the current browsers are a bit wonky when it comes to what elements and attributes they do and don’t support. For example, Opera seems to support email validation, just as long as the
name attribute is specified. However, it does not support the
placeholder attribute, which we’ll learn about in the next tip. Bottom line, don’t depend on this form of validation just yet…but you can still use it!
value attribute how you see fit, but, as soon as the user deletes that text and clicks away, the input will be left blank again. The
placeholder attribute remedies this.
Again, support is shady at best across browsers, however, this will continue to improve with every new release. Besides, if the browser, like Firefox and Opera, don’t currently support the
placeholder attribute, no harm done.
9. Local Storage
Thanks to local storage (not officially HTML5, but grouped in for convenience’s sake), we can make advanced browsers “remember” what we type, even after the browser is closed or is refreshed.
While obviously not supported across all browsers, we can expect this method to work, most notably, in Internet Explorer 8, Safari 4, and Firefox 3.5. Note that, to compensate for older browsers that won’t recognize local storage, you should first test to determine whether window.localStorage exists.
10. The Semantic
Gone are the days of:
Divs, by nature, have no semantic structure — even after an
id is applied. Now, with HTML5, we have access to the
<footer> elements. The mark-up above can now be replaced with:
It’s fully appropriate to have multiple
footers in your projects.
Try not to confuse these elements with the “header” and “footer” of your website. They simply refer to their container. As such, it makes sense to place, for example, meta information at the bottom of a blog post within the
footer element. The same holds true for the
11. Internet Explorer and HTML5
Unfortunately, that dang Internet Explorer requires a bit of wrangling in order to understand the new HTML5 elements.
All elements, by default, have a
In order to ensure that the new HTML5 elements render correctly as block level elements, it’s necessary at this time to style them as such.
Unfortunately, Internet Explorer will still ignore these stylings, because it has no clue what, as an example, the
header element even is. Luckily, there is an easy fix:
Strangely enough, this code seems to trigger Internet Explorer. To simply this process for each new application, Remy Sharp created a script, commonly referred to as the HTML5 shiv. This script also fixes some printing issues as well.
12. Required Attribute
Forms allow for a new
required attribute, which specifies, naturally, whether a particular input is required. Dependent upon your coding preference, you can declare this attribute in one of two ways:
Or, with a more structured approach.
Either method will do. With this code, and within browsers that support this attribute, a form cannot be submitted if that “someInput” input is blank. Here’s a quick example; we’ll also add the placeholder attribute as well, as there’s no reason not to.
If the input is left blank, and the form is submitted, the textbox will be highlighted.
13. Autofocus Attribute
Interestingly enough, while I personally tend to prefer a more XHTML approach (using quotation marks, etc.), writing
"autofocus=autofocus" feels odd. As such, we’ll stick with the single keyword approach.
14. Audio Support
No longer do we have to rely upon third party plugins in order to render audio. HTML5 now offers the
<audio> element. Well, at least, ultimately, we won’t have to worry about these plugins. For the time being, only the most recent of browsers offer support for HTML5 audio. At this time, it’s still a good practice to offer some form of backward compatibility.
Mozilla and Webkit don’t fully get along just yet, when it comes to the audio format. Firefox will want to see an .ogg file, while Webkit browsers will work just fine with the common .mp3 extension. This means that, at least for now, you should create two versions of the audio.
When Safari loads the page, it won’t recognize that .ogg format, and will skip it and move on to the mp3 version, accordingly. Please note that IE, per usual, doesn’t support this, and Opera 10 and lower can only work with .wav files.
15. Video Support
Much like the
<audio> element, we also, of course, have HTML5 video as well in the new browsers! In fact, just recently, YouTube announced a new HTML5 video embed for their videos, for browsers which support it. Unfortunately, again, because the HTML5 spec doesn’t specify a specific codec for video, it’s left to the browsers to decide. While Safari, and Internet Explorer 9 can be expected to support video in the H.264 format (which Flash players can play), Firefox and Opera are sticking with the open source Theora and Vorbis formats. As such, when displaying HTML5 video, you must offer both formats.
Chrome can correctly display video that is encoded in both the “ogg” and “mp4” formats.
There are a few things worth noting here.
- We aren’t technically required to set the
typeattribute; however, if we don’t, the browser has to figure out the type itself. Save some bandwidth, and declare it yourself.
- Not all browsers understand HTML5 video. Below the
sourceelements, we can either offer a download link, or embed a Flash version of the video instead. It’s up to you.
preloadattributes will be discussed in the next two tips.