• Cookies expire and get cleared a lot, localStorage is forever (until explicitly cleared).
• localStorage isn't sent along in HTTP Requests, you have to ask for it.
• You can store way more data in localStorage than you can in cookies.
• The API for localStorage is wicked simple and easy.

If you need to get more up to speed, I did a video screencast on localStorage recently. This is how it works:

/* Set some data */
//AN_Xml:localStorage.setItem("key", "value");
//AN_Xml:
//AN_Xml:/* Get some data */
//AN_Xml:localStorage.getItem("key");

No libraries needed, that's just JavaScript. If you want you can use Modernizr to test for it with Modernizr.localstorage first.

OK great that's all the geeky bits, let's see some places on the web that could be, should be, or are using it. Hopefully this will spark some ideas for your own websites.

IS using localStorage

Snapbird (a powerful Twitter search tool) remembers the last person's stream you searched. It figures, chances are, the next time you come back you'll be searching that same person and this will save you a second. If not, you can just delete it and replace it. I find it useful as I'm typically trying to find old tweets of my own.

The Webbie Madness event this year had a large March Madness style voting grid where people were encouraged to come pick winners in multiple rounds. The first round had 32 people in 16 battles. The peoples names were disguised. It took a while to figure out who was who and decide who to vote for, and it wasn't something I was able to do in one "sitting". I suggested they save the votes as people did them to localStorage, that way you could come back any time and finish. Like total badasses, they did it!

JSBin (By Remy Sharp, who did Snapbird also, go figure) allows you to save your starter HTML/JavaScript template so the next time you come back to use it, you can use that same template.

SHOULD be using localStorage

Typekit has a Type Tester tool when viewing a particular font. You can type your own text into the box to see what it will look like in that font. Unfortunately when you go to another font, that custom text you entered is gone. This would be a great case for localStorage. When the value in that area changes, save it to localStorage, and load that value in when the page loads. I think that would be a great timesaver, as I think jumping around to see that text in multiple fonts is a pretty common use case.

CSS Lint has a grid of checkboxes for what features you do/don't want to CSS Lint to look for when you test your CSS. It would be really nice if this used localStorage to remember what checkbox configuration you used, so if you reload the page or come back later, it's the same. So if you don't like the "Don't use IDs" checkbox, you can turn if off forever =).

Pretty much any website with a login form could use localStorage to keep the username saved. So when a user comes back, it's one less step for them to log in.

Zeldman.com has links in the footer which allow you to toggle the colors used on the site between two versions. It saves this as a cookie which is great, but is subject to the frailty of cookies. Any site like this with alternate styling choices (e.g. font-size toggle) could save that information in localStorage and have it persist better.

MOR

This is the tip of the iceberg. I'm sure people with more developer-oriented minds can think of bigger and better ideas for this. Saving your place in a game? Caching assets? What else you got?

Way more info from Mark Pilgrim.

Advertise here with BSA

Examples of Sites where localStorage should or is being used is a post from CSS-Tricks

It looks like this:

<button>
//AN_Xml:  Do Something
//AN_Xml:</button>

What's the most common result of clicking something on a website? Moving to a new URL, like you would clicking a link (an <a href="/example/"></a>) element).

The <button> element, by itself, can't do that. There have been various conversations about allowing "href anywhere" over the years, but nothing has came of it.

Clicking on a button does do something though, when used in its natural environment...

Button is a Form Element

Web forms have submit buttons. You might think of that like this:

<form action="/" method="post">
//AN_Xml:  <input type="submit" value="Submit">
//AN_Xml:</form>

A <button> element in a <form>, by default, behaves identically to that submit input above.

<form action="/" method="post">
//AN_Xml:  <button>Submit</button>
//AN_Xml:</form>

However gross the UX, forms can have reset buttons as well. You can duplicate that behavior by changing the default submit type to reset.

<form action="/" method="post">
//AN_Xml:  <button type="reset">Reset</button>
//AN_Xml:</form>

Clicking that button will clear all the other inputs (and textareas) with the parent <form>.

Buttons can have content

The primary reason for using a <button> is that it has both and opening and closing (</button>) tag. Which means there can be stuff inside. A common use case would be something like:

<button>
//AN_Xml:  <img src="tiny_birthday_cake.png" alt="">
//AN_Xml:  Submit
//AN_Xml:</button>

While an input can be <input type="image">, this mixed content would be hard to pull off.

As far as I can tell, there is no limit to what kind of content you can put in a button, so feel free to get real weird with it. Pseudo elements can be used too.

Let's leave styling <button>s for another day, but different browsers generally have a special style they apply to buttons. You'll want to either leave that alone so the default comes through, or remove it thoroughly so your new styling can be consistent across browsers.

Let's consider: "if a button doesn’t have a meaningful href, it’s a <button>"

I said recently that I enjoyed that sentiment. That's what kicked off this article for me. At the time, I was thinking of how I enjoyed the semantics of it. As in:

<a href="#0">
//AN_Xml:  I'm kinda sick of doing this for buttons.
//AN_Xml:</a>

There is no meaningful href there. The 0 is just there so it doesn't jump the page, because ID's can't start with a number.

Chances are, HTML like the above means: I'm going to make clicking that do something with JavaScript. Somehow that feels better than a <div> whatever, because you get the cursor change and whatever else default styles.

If you don't like those meaningless href's, a <button> can seem like a nice alternative. But unfortunately outside of the context of a <form>, a <button> is equally meaningless.

<button>
//AN_Xml:  Outside of a <form>, I'm just as useless.
//AN_Xml:</button>

But <button> feels better anyway

Even if a <button> doesn't do anything outside of a form without the help of JavaScript, it still feels better for things you can click that do stuff other than change pages. A bogus href link definitely doesn't feel right.

Alright. Let's insert it with JavaScript then.

That's probably the best solution. If JavaScript is required for the clickable-thing to do anything at all, it might as well not even be there at all unless JavaScript runs. We can do:

// 1. Create the button
//AN_Xml:var button = document.createElement("button");
//AN_Xml:button.innerHTML = "Do Something";
//AN_Xml:
//AN_Xml:// 2. Append somewhere
//AN_Xml:var body = document.getElementsByTagName("body")[0];
//AN_Xml:body.appendChild(button);
//AN_Xml:
//AN_Xml:// 3. Add event handler
//AN_Xml:button.addEventListener ("click", function() {
//AN_Xml:  alert("did something");
//AN_Xml:});

You could easily have "button adding" be a part of your JavaScript workflow.

When links make more sense

If there is any kind of href you could put on that link that makes sense, by all means, use an anchor. Even if you override that behavior with JavaScript. That's progressive enhancement at it's finest. For instance:

//AN_Xml:
• A search button normally triggers a type-ahead ajax-search thingy - but the href could just point to a /search/ page.
//AN_Xml:
• A publish button triggers the the next stage of publishing something a user built - but the href could just point to a /publish/ page.
//AN_Xml:
• A thumbnail button opens a lightbox with a larger version - but the href could just point to the URL of that larger version.
//AN_Xml:

If nothing makes sense, insert the button with JavaScript.

Accessibility concerns

Let's say using an anchor link does make sense. After you give yourself a nice little back-pat for being good at progressive enhancement, there is accessibility to consider as well.

You might be like, I got this!

<a href="#meaningful" class="button" role="button">
//AN_Xml:  I'm good
//AN_Xml:</a>

But you aren't out of the woods yet. MDN covers it well:

Warning: Be careful when marking up links with the button role. Buttons are expected to be triggered using the Space key, while links are expected to be triggered through the Enter key. In other words, when links are used to behave like buttons, adding role="button" alone is not sufficient. It will also be necessary to add a key event handler that listens for the Space key in order to be consistent with native buttons.

Get that? You activate links and buttons with different keys, so consider that.

Go forth and uhm, make clickable things correctly.

When To Use The Button Element is a post from CSS-Tricks