Deze vertaling is niet volledig. Help dit artikel te vertalen vanuit het Engels.
The Web Storage API provides mechanisms by which browsers can store key/value pairs, in a much more intuitive fashion than using cookies.
Webopslag concepten en gebruik
The two mechanisms within Web Storage are as follows:
sessionStoragemaintains a separate storage area for each given origin that's available for the duration of the page session (as long as the browser is open, including page reloads and restores)
localStoragedoes the same thing, but persists even when the browser is closed and reopened.
These mechanisms are available via the
Window.localStorage properties (to be more precise, in supporting browsers the
Window object implements the
WindowSessionStorage objects, which the
sessionStorage properties hang off) — invoking one of these will create an instance of the
Storage object, through which data items can be set, retrieved and removed. A different Storage object is used for the
localStorage for each origin — they function and are controlled separately.
- Allows you to set, retrieve and remove data for a specific domain and storage type (session or local.)
- The Web Storage API extends the
Windowobject with two new properties —
Window.localStorage— which provide access to the current domain's session and local
storageevent is fired on a Document's
Windowobject when a storage area changes.
To illustrate some typical web storage usage, we have created a simple example, imaginatively called Web Storage Demo. The landing page provides controls that can be used to customize the colour, font and decorative image. When you choose different options, the page is instantly updated; in addition the your choices are stored in
localStorage, so that when you leave the page then load it again later on your choices are remembered.
In addition, we have provided an event output page — if you load this page in another tab, then make changes to your choices in the landing page, you'll see the updated storage information outputted as the
StorageEvent is fired.
|Web Storage (Second edition)||Recommendation|
|Feature||Chrome||Firefox (Gecko)||Internet Explorer||Opera||Safari (WebKit)|
|Feature||Android||Firefox Mobile (Gecko)||IE Phone||Opera Mobile||Safari Mobile|
|Basic support||2.1||?||8||11||iOS 3.2|
All browsers have varying capacity levels for both localStorage and sessionStorage. Here is a detailed rundown of all the storage capacities for various browsers.
Note: since iOS 5.1, Safari Mobile stores localStorage data in the cache folder, which is subject to occasional clean up, at the behest of the OS, typically if space is short.
Privé Browsen / Incognito modus
Most browsers these days support a privacy option called 'Incognito' or 'Private Browsing' mode etc that basically makes sure that the private browsing session leaves no traces after the browser is closed. This is fundamentally incompatible with Web Storage for obvious reasons. As such, browser vendors are experimenting with different scenarios for how to deal with this incompatibility.
Most browsers have opted for a strategy where storage APIs are still available and seemingly fully functional, with the one big difference that all stored data is wiped after the browser is closed. For these browsers there are still different interpretations of what should be done with existing stored data (from a regular browsing session). Should it be available to read when in Private mode? Then there are some browsers, most notably Safari, that have opted for a solution where storage is available, but is empty and has a quota of 0 bytes assigned, effectively making it impossible to write data to it.
Developers should be aware of these different implementations and take them into account when developing websites depending on Web Storage APIs. For more information please have a look at this WHATWG blog post that specifically deals with this topic.