HTML and CSS Reference
fire a reload, effectively causing the browser to rerender the content, make a request to the servers, and fire any ad
The history API has a bunch of useful features, and it can also be fun to use in your next advertising campaign.
For example, you could build a creative that pretends to know where the user visited last. Yes, kind of creepy; it may
frighten a few users and even get some backlash, but it's really harmless, since you're not gathering any personally
identifiable information. You'd simply be calling upon the history records in the browser's stored memory.
The API can get a bit tricky for ad developers. Let's say users are browsing around the ad content, perhaps
searching for different products in a dynamic product feed and the developer has each user interaction logged to the
history of the browser. Now, if the user uses the back button of the browser, it would just return to the state previously
viewed in the ad content instead of going back to the previous page content. While this is all very new and emerging,
we'll have to see where digital advertising fits within its use of the history API; it could conflict with many things and
may even be off-limits to digital advertising all together. However things play out, the history API is worth familiarizing
yourself with; I've even seen interesting examples that replicate the old marquee of scrolling text but, in this case, in
the URL bar.
It's interesting how publishers and content makers will implement the history API in their pages. For example,
when working with the API and adjusting the user's browser state, if no page reload happens, the ad content on the
screen doesn't reload; thus no impression will fire. However, someone has seen the content again and it could even be
someone entirely new, which should account for a new impression, right?
For more information on the History API, check out Opera's dev channel by visiting http://dev.opera.com/
Saving data is a pretty common task in any application, and with HTML5 it's becoming even more important on the
Web. Sometimes you'll want to store data to reference at a later time; other times you can use the data saved with
the HTML5 history API about users' browsing history. You can even save data for offline viewing, as you'll learn in
Chapter 10. No matter which way you look at it, storage is a huge feature in software development so let's take a look at
working with the web storage API in HTML5.
There are two types of web storage you need to remember.
localStorage : saves data without an expiration date
sessionStorage : saves data for one browsing session
Data in localStorage persists past browser restarts, whereas sessionStorage sticks around only when the page
is refreshed. This specification is an API for data storage of a name/value pair of data in the browser. This is pretty
revolutionary because you do not have to request the saved information via a server request; everything is saved
client-side. Modern browsers typically allow up to 5 megabytes of client-side storage, whereas in HTML4, a cookie was
used to store small amounts of information about a user's session, up to 4 kilobytes of storage, and it traveled
with every HTTP request. Now you can save images into a string of text via Base64 encoding and save that within
the browser's 5 megabytes of storage per domain (approximately). Another nice feature is that if you attempt to
exceed the default storage amounts set by the browser, the browser will ask the user to allow or deny the storage of
Now sessionStorage is a method of storing client-side data (name/value pairs) locally—much like cookies but it has
many more advantages. Through sessionStorage , you can now save data from a user's browsing session in memory
for retrieval at a later time in the ad experience, all without multiple round trips to a server. The real power in using
sessionStorage is that it's supported across all major browsers, even down to IE8! Again, it's action is similar to that
of cookies, but unlike cookies, web storage data are not sent with every server request and do not have the same data