HTML and CSS Reference
In-Depth Information
Looking at how cookies work, they're overly complicated.
Setting a cookie in JavaScript looks like this:
document.cookie = “foo=bar; path=/”;
That's a session-based cookie. Now, if I want to store something
for longer, I'll have to set it in the future, and give it a specific
lifetime (and if I want it to persist, I'll have to keep setting this to
be n days in the future):
document.cookie = “foo=bar; path=/; expires=Tues,
¬
13 Sept 2010 12:00:00”;
The time format is important too, which only causes more head-
aches. Now, the icing on the horrible-tasting cookie: To delete a
cookie, I need to set the value to blank:
document.cookie = “foo=; path=/”;
In fact, the cookie isn't really deleted, it's just had the value
changed and had the expiry set to a session, so when the
browser is shut down. Delete should really mean delete.
Cookies don't work because they're a headache. The new stor-
age specifications completely circumvent this approach to set-
ting, getting, and removing data by offering a clean API.
note
The only saving
grace of cookies, and what
makes them work, is the fact
that they're shared with the
server via a request header. This
can be used to help prevent
security exploits; otherwise, in
most cases, I've found web stor-
age kicks a cookie's butt!
Storage options
There are two options when it comes to storing data on the
client side:
•
Web Storage—supported in all the latest browsers
•
Web SQL Databases—supported in Opera, Chrome,
and Safari
Conveniently, Web SQL Databases is so named to instantly give
you a clue as to how it works: It uses SQL-based syntax to query
a local database.
Web Storage is a much simpler system in which you simply
associate a key with a value. No learning SQL required. In fact,
support for the Web Storage API is much better than for Web
SQL Databases. I'll look at both of these APIs, how they work,
and how to debug data in each system.
