1. New Doctype
Still using that pesky, impossible-to-memorize XHTML doctype?
1
2
| <! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" |
1
| <! DOCTYPE html> |
doctype
. Browsers that do not
understand this doctype will simply render the contained markup in
standards mode. So, without worry, feel free to throw caution to the
wind, and embrace the new HTML5 doctype. 2. The Figure Element
Consider the following mark-up for an image:
1
2
| < img src = "path/to/image" alt = "About image" /> < p >Image of Mars. </ p > |
<figure>
element. When combined with the <figcaption>
element, we can now semantically associate captions with their image counterparts.
1
2
3
4
5
6
| < figure > < img src = "path/to/image" alt = "About image" /> < figcaption > < p >This is an image of something interesting. </ p > </ figcaption > </ figure > |
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.
The small
element now refers to "small print."
4. No More Types
for Scripts and Links
You possibly still add the type
attribute to your link
and script
tags.
1
2
| < link rel = "stylesheet" href = "path/to/stylesheet.css" type = "text/css" /> < script type = "text/javascript" src = "path/to/script.js" ></ script > |
type
attribute all together.
1
2
| < link rel = "stylesheet" href = "path/to/stylesheet.css" /> < script src = "path/to/script.js" ></ script > |
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.
1
| < p class = myClass id = someId > Start the reactor. |
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.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
| <! DOCTYPE html> < html lang = "en" > < head > < meta charset = "utf-8" > < title >untitled</ title > </ head > < body > < h2 > To-Do List </ h2 > < ul contenteditable = "true" > < li > Break mechanical cab driver. </ li > < li > Drive to abandoned factory < li > Watch video of self </ li > </ ul > </ body > </ html > |
1
| < ul contenteditable = true > |
7. Email Inputs
If we apply atype
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.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
| <! DOCTYPE html> < html lang = "en" > < head > < meta charset = "utf-8" > < title >untitled</ title > </ head > < body > < form action = "" method = "get" > < label for = "email" >Email:</ label > < input id = "email" name = "email" type = "email" /> < button type = "submit" > Submit Form </ button > </ form > </ body > </ html > |
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!8. Placeholders
Before, we had to utilize a bit of JavaScript to create placeholders for textboxes. Sure, you can initially set thevalue
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.
1
| < input name = "email" type = "email" placeholder = "doug@givethesepeopleair.com" /> |
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."localStorage sets fields on the domain. Even when you close the browser, reopen it, and go back to the site, it remembers all fields in localStorage."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.
-QuirksBlog
10. The Semantic Header
and Footer
Gone are the days of:
1
2
3
4
5
6
7
| < div id = "header" > ... </ div > < div id = "footer" > ... </ div > |
id
is applied. Now, with HTML5, we have access to the <header>
and <footer>
elements. The mark-up above can now be replaced with:
1
2
3
4
5
6
7
| < header > ... </ header > < footer > ... </ footer > |
It's fully appropriate to have multipleTry 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 theheader
s andfooter
s in your projects.
footer
element. The same holds true for the header
.