HTML5 Demos

Useful HTML5 Features

• Meters
  HTML5's meter tag allows you show a meter that can be progressively filled or emptied. It's designed to be used with a defined range (like 0 to 100) and is not supposed to be used as a progress bar (that's what the progress tag is for). A meter can be dynamically manipulated via JavaScript, so it is actually more useful than a progress bar for many tasks. For example, you could use it in a game to track the number of times you successfully hit a target over time: 3 hits out of 5 attempts, 3 out of 6, 4 out of 7, etc. Although the "defined" range changes with each attempted hit, the range is always defined at all times.
• The bad news is that, at this time, not all major browsers support the meter tag well—or even at all. One way to handle this is have a fallback for the problematic browsers (for example, a gauge bar done in CSS).
  
  6

  The meter is 6/7th filled.

• Progress Bars
  HTML5's progress tag allows you show a progress bar that fills based on the progress to a specified maximum. It's not supposed to be used as a meter or gauge (that's what the meter tag is for). The filled part of the bar is animated. On its own, the progress bar does not dynamically update, as it has no way to know what it is supposed to be tracking. It can be dynamically updated via JavaScript, so as long as you can track via JavaScript the progress of what you want to measure.
• Once again, the bad news is that, at this time, not all major browsers support the progress tag well—or even at all. One way to handle this is have a fallback (for example, a progress bar done in CSS), although this increases the work to be done.
• Progress Bar 1
  This bar updates at intervals of one second. This clearly demonstrates the updating pace, but the jumpy pace makes for a less-than-ideal experience for the end user.
  
  UNSUPPORTED

  Use the Start button to see the bar fill as 10 seconds elapse.
• Progress Bar 2
  This bar updates at intervals of one-twentieth of a second, which makes for a better experience for the end user.
  
  UNSUPPORTED

  Use the Start button to see the bar fill as 10 seconds elapse.
• Data Attributes
  HTML5 allows you to add custom attributes to any HTML element, as long as you start each attribute's name with data-. This allows you to directly embed custom data for an element in a way that won't be displayed when the page is rendered but is available for use by JavaScript. The values in these attributes are accessible even in non-HTML5 browsers, through JavaScript's getAttribute() method or via jQuery, which is what this demo uses. (jQuery is quite useful for this, as you can't yet count on accessing the values of data attributes using the DOM dataset property. While most modern browsers support the property, support is not universal, and many older browsers still in widespread use don't support it at all.)
• The demo box below has a data attribute in the HTML containing help text, and JavaScript is used to display this help text when you hover the mouse over the box.
  

  Put the mouse over this box!

   

• The HTML code used to define the box and the data help is:

  <div class="demoDivs" id="dataDemo" data-help="Help text for this item.">  

• User Editable Content
  contenteditable="true" can be added to very many elements, and it allows the user to edit the content of the element. This is useful, for example, for things users may want to change, like their contact information. By itself, contenteditable doesn't actually save what the user enters, but the data can be saved in various ways, such as by JavaScript using AJAX, JSON, or by local storage.
  

  You can change the text in this box. Go ahead and try it. (Changes won't be saved.)
• The default behavior of a contenteditable element is that the cursor is placed based on where the user clicks in the element, and none of the content is selected. This behavior can be changed using JavaScript. For the demo below, it's assumed that if the user clicks in the box to change the content, the user will want to change all the content, and so all the content is automatically selected.
  

  When you click in the box, all the content will be selected. (Changes won't be saved.)
• Attributes and Types for Input Tags
  HTML5 gives input tags additional attributes that increase their utility. It also has many new types for input tags, which makes creating UI controls and getting user input easier. That is, once they have widespread support in browsers. Currently, even some modern browsers don't support all the new types. Also, some modern mobile browsers only have incomplete support.
• If a browser doesn't support one of the new attributes, the attribute is ignored. If it doesn't support one of the new input types, the type defaults to "text" and, under default operation, the browser displays a text field. In these demos, I use JavaScript/jQuery to check for support of these items and display "UNSUPPORTED" if no support is detected.
  

  Input Attribute	Example	Notes
  <input ... autofocus>	If JavaScript is enabled in your browser, this box will display whether your browser supports autofocus.	Various elements, including input tags, can use the autofocus attribute to cause the browser to put the focus on that element when the page loads. autofocus is extremely useful for forms, as the user doesn't have to click or otherwise interact with the page just to start using the form. However, autofocus should only be used on pages where use of the control or input is the expected first interaction with the page. Otherwise, the page may behave differently than the user is expecting. For example, if the page loads with the autofocus on an element that is off screen, the user may take actions that actually interact with the off-screen element and not see anything happen on screen. That's why this autofocus demo is designed to be run on its own. Note: autofocus does not play well when loaded into a page using AJAX. The HTML5 specification did not specify when to check for autofocus in sufficient detail to ensure consistent usage across all browsers. Accordingly, browsers have implemented it in different ways. Some browsers (some versions of Firefox and Safari, for example) only check for autofocus on the initial page load but not when new content is downloaded via AJAX. Others check for autofocus when new content is downloaded via AJAX and adjust the focus accordingly. So, either do not use autofocus in AJAX-downloadable content or supply a JavaScript fallback to autofocus to ensure you get what you want.
  <input ... placeholder="Start typing here">		Many input types can use the placeholder attribute to show placeholder text (like help information) for the input. The placeholder text disappears when the user starts to type in the field.
  <input ... list="listExample">		Many input types can use the list attribute to associate an autocomplete list for the input. In the text box to the left, enter one of the following: a, b, or c (either case), and you will get an autocomplete suggestion. Choosing a suggestion then fills the field with the value associated with the suggestion.
  <input ... required>		Text field input types can use the required attribute to ensure that the field contains user input before it is submitted. When the user uses the Submit button, the input is checked. If it is empty, the browser displays an error prompt. For this demo, leave the text field empty and press Submit.
  <input ... pattern="[1-3]{1}">		Many input types can use the pattern attribute to provide a JavaScript regular expression pattern. When the user uses the Submit button, the input is checked against the pattern. If the input is incorrect, it is not submitted, and the browser displays an error prompt. For this demo, the input can only be a single number and can only be one of the following: 1, 2, or 3.
  Input Type	Example	Notes
  <input ... type="range">		This input type creates a slider for users to graphically select a number in a range of numbers. Note that the control does not display the number the slider is at (you can do this with JavaScript).
  <input ... type="number">		This input type allows users to select a number (in this case, from 0 to 50 in steps of 5, with a default of 15).
  <input ... type="color">		This input type allows users to pick a color.
  <input ... type="date">		This input type allows users to pick a date. There are also input types for selecting a month, week, time, date & time, and local date & time.
  <input ... type="email">		This input type allows users to enter an email address. A default address can be supplied. Some browsers that support the type try to check if the user's entry is a well-formed email address and take some action if it is not.
  <input ... type="url">		This input type allows users to enter a URL. A default URL can be supplied. Some browsers that support the type check if the user's entry is a well-formed URL and display a prompt if it is not. Safari v5.1.7 for Windows supports the type but does not check the address. You can't effectively use pattern to provide your own check, as even though Safari v5.1.7 recognizes this attribute, it doesn't do anything with it. (JavaScript of course could be used to check the user's entry.)
  <input ... type="tel">		This input type allows users to enter a telephone number. A default number can be supplied.
  <input ... type="search">		This input type allows users to enter text for a search. Currently, all browsers that support this type show the input field exactly like a text field, although this might change someday.

Canvas and WebGL

• Canvas
  The HTML5 canvas allows web pages to specify areas where images and animations are displayed, without the need for custom or proprietary browser plugins or extensions. These images and animations are defined and controlled with JavaScript.
  

  Relative Sizes of the Sun and Planets

  Your browser does not support the HTML5 canvas.

  
  The above canvas shows the relative sizes of the sun and major planets. Everything on the canvas is done with HTML5 canvas commands, CSS, and JavaScript.
• It can be code-intensive to use the HTML5 canvas on your own for anything but the simplest of drawings, as you're doing low-level operations. This is the case even for static drawings, and animations can be very code-intensive. The canvas on its own also isn't as powerful as Flash, as there's no built-in stage or timeline. However, the solution to these issues is to use a canvas library. Some options include KineticJS, a high-performance canvas JavaScript framework, TweenJS, a tweening library, EaselJS, a JavaScript canvas library, LibCanvas, jCanvaScript, and various other libraries.
• RGraph is a canvas library that does great charts, gauges, and meters. Let's do a couple of RGraph demos!
  

  Your browser does not support the HTML5 canvas.

  
  Chart created by RGraph
  The above pie chart shows how the masses of the outer gas giant and ice giant planets compare. The pie chart is simple and uses a key. The key is interactive; click on an item in the key to show it with the rest of the chart de-emphasized. (Click outside the key to restore the chart.)

• Your browser does not support the HTML5 canvas.

  
  Chart created by RGraph
  The above pie chart shows how the masses of the inner rocky planets compare. The pie chart is has more effects and uses labels instead of a key. The pie wedges are interactive; click on a wedge to see its planet's name in a tooltip. (Click outside the wedges to restore the chart.)
• WebGL
  WebGL is based on OpenGL and is an API that allows you to write code that executes on the GPU hardware. Among other things, this gives you the ability to display 3D and 2D graphics using the canvas, without the need for a browser plugin. Modern browsers can use WebGL, but older ones cannot (Internet Explorer 11 has only partial support, and earlier IEs none at all, for example). WebGL is not simple! You'll need to know JavaScript and the basics of 3D graphics programming; some knowledge of C/C++ is also useful. There's no demo here, but if you have a WebGL-capable browser, you can see a simple example at https://get.webgl.org

Video and Audio

• Video
  The HTML5 video tag allows web pages to natively display videos, without the need for plugins or extensions. Good news! Unfortunately, as it seems to have always been the case with the web since Microsoft decided to destroy Netscape, there's bad news, too. The major browsers use different technologies, so you have to process and provide the video for at least two "containers:"
  
  1. WebM (for VP8 or VP9 video and Vorbis audio), which can be used by Chrome 6+, Firefox 4+, Opera 10.6, and Android (and also by browser-independent Flash 9+).
  2. MP4 (for H.264 video and AAC audio), which can be used by Chrome 3+, Internet Explorer 9+, Safari 3+, and iOS (and also by browser-independent Flash 9+).
  3. OGG (for Theora video and Vorbis audio), which can be used by Chrome 3+, Firefox 3.5+, Opera 10.5+, and Android.
  Unless you need to support Firefox 3.5/3.6 and Opera 10.5 instead of just Firefox 4 and Opera 10.6+, you can skip OGG, as WebM will do the trick.
• There's many more issues involved with video and audio, like iOS devices only supporting "baseline" H.264 and "low complexity" ACC, as well as the contortions of H.264 licensing (which is why some browsers avoid using H.264), plus making sure your web server has the correct MIME types for ogg, webm, and mp4 (which can be a killer if your hosting service is set up incorrectly and you can't change it), and let's not even go into codecs at all. If you care about these details you can do a web search and easily find endless hours of reading material. Me, I'd rather do a demo!
  
  The demo uses the native controls built into the browser, rather than providing custom ones. To play it, just click the start triangle, wherever it may be (it varies a bit between browsers). If you don't see any controls, you're probably using IE9+, so just put the mouse over the video box to get the controls.
• The video isn't preloaded, so it can take a few seconds to start after you click the triangle. Safari users can encounter a delay of several seconds. For anything more than a demo, it'd be a good idea to show a loading animation via JavaScript or a JavaScript video library until video actually started. (Some browsers natively show a loading animation, but not all of them.)
• If you see "Your browser doesn't support HTML5 video" above, well, that kind of says it all. Fallbacks would be 1) also have the video in Flash video format and play it in the Flash player (the video tag allows a Flash object to be included but used only if no HTML5 video source runs), and 2) simply allow the user to download the file and run it locally. However, I'm demoing HTML5 video here and not fallbacks.
• Audio
  The HTML5 audio tag works quite similar to the video tag and allows web pages to natively play audio files, without the need for plugins or extensions. Like video, you need to include multiple formats to handle all the major browsers: .mp3 and .ogg files do the trick. Demo time!
  
  
  The demo uses the native controls built into the browser, rather than providing custom ones. To play it, just click the start triangle, wherever it may be (it varies a bit between browsers).
• If you see "Your browser doesn't support HTML5 audio" above, well, that kind of says it all. Fallbacks would be 1) also have the audio in a Flash object in the audio tag (see the HTML video demo above for more details), and 2) simply allow the user to download the file and run it locally. However, I'm demoing HTML5 audio here and not fallbacks.

Local and Session Storage

• Local Storage
  Local storage is a way to store data on the user's browser. Persistent local data has been an issue from the start of the web, as browsers originally were stateless: data generated by the user did not persist locally between sessions or even between page navigation. That limited the ability of web sites to do certain things, so various state-retaining solutions were quickly implemented. Some examples are server-side storage accessed via user names/passwords, browser cookies, and proprietary schemes like Flash local shared objects aka "Flash cookies."
• HTML5 local storage is a good improvement to this situation. Approximately, each web page/app (that obeys the same origin policy) can use local storage per "user browser" (each browser that a user account is using). Many browsers grant 5-10 MB of storage per site, although some mobile devices provide only 2.5 MB (and I've read of at least one having a total of 6 MB that is shared by all sites using local storage). Some browsers allow "unlimited" storage (not quite true unless the browser can access infinite memory). Some browsers with maximum storage limits allow the user to increase the storage limit.
• It's demo time! The following box shows whether or not your browser supports local storage. Unlike feature detection schemes, it goes beyond trying to create a local store and then just detecting its existence. Instead, it is a feature testing scheme and determines whether data can be successfully saved and retrieved. (For example, this catches that an iOS 5 device in private browsing mode cannot actually use local storage, even though it would pass a local storage detection test.) No data is permanently saved in this test as the test data, if successfully saved, is then deleted.
  

  Test results will appear here if JavaScript is enabled.

• If you do have local storage, this next demo lets you enter text to be saved. Just fill out the fields as you like and click Save. You can see what you saved on the right. If you refresh the browser or close it and restart it, you'll see that your entries are saved. Click Delete when you want to get rid of the saved data.
  
  
  
  

  Your saved entries:

  •  
  •  
• Local storage has some limitations and restrictions:
  • It is very local. If you're interested in building persistent user data storage across browsers and devices, local storage is not your solution. Local storage is based on user account and browser. If a users runs your page/app on two different browsers on the same device (like a PC or laptop), each has its own independent local storage ability. You can easily test this by running this page on the same device in two browsers. This isn't a flaw, and local storage is still extremely useful for many purposes, but cross-browser persistent data is not one of these.
  • Local storage is also based on user account, as mentioned above. Different user accounts on a device, even when using the same browser, cannot access another profile's or user account's local storage. This of course makes tons of sense for security and usability reasons.
  • One thing to know is that, for a single browser for a user account, all instances of the web page/app running in that browser share that page's/app's locally stored data. (Open this page in two windows or tabs in the same browser and experiment to see this. One thing to remember, however, is that if your saved data is already displaying in one window/tab and you update it in the other, for this demo you will need to refresh the former window/tab to update the display. A storage event listener could have been created to update the other window/tab when a storage event occurs, but this does not seem to be fully reliable for all possibilities; see this Stack Overflow local storage issue.)
  • The above explanation is a bit simplified. The same-origin policy means, for example, that your page delivered over https does not share local storage with your page delivered over plain http. Similarly, private or incognito browsing has its own separate local storage.
  • Local storage can only store strings. Numeric data is converted to string data when stored and thus is a string when you retrieve it later. If you plan to use it as a number once retrieved, you either must convert it yourself back to a number or ensure that the operation that uses it will automatically convert it correctly. In JavaScript, however, '5' + 1 = '51' (the five is a string, the 1 is a number, and JavaScript in this context interprets the plus sign as string concatenation. Thus, the 1 is converted to a string and is placed at the end of the '5' string.) Some day, local storage will allow other types of data to be stored.
  • Since local storage uses strings, arrays and objects cannot be stored directly (at least, not in a way useful way, unless you think storing '[object Object]' is useful). Instead, you need to serialize arrays and objects when saving them and rebuild them when retrieving their data. One way to do this is to use JSON to stringify and parse the data.
  • Also, a string is not an efficient way to store numeric data. Storing a lot of numbers, particularly long floating point numbers, can chew up storage memory.
  • Local storage is persistent. OK, this is a good feature and not a limitation, but it is up to your code to behave properly. The data persists until either the page/app deletes the data or the user does something to the browser to delete the data. A well-behaved page/app should be responsible in using local storage, such as only storing data this is really needed, purging it when not needed, and, depending upon the situation, giving users options to delete the data. Also, again depending upon circumstances, if it is not obvious that your page is going to be storing local data, it may be best to inform the user about this (or get their permission). Etc.
  • Designs should also not assume that lack of local storage data means the user has not used the page/app before, as they may have deleted the stored data. (For example, avoid forcing the user to go through a long, unskippable tutorial for your app just because there's no tutorialCompleted='true' in the data store.)
  • Possible user backlash. Another thing to watch out for is possible user backlash against malicious use of local storage. How about scammers trying to fill up your hard disk with junk using local storage and then trying to get you to pay them to delete the junk? Browsers that grant unlimited storage seem vulnerable, and even browsers that only grant 5 or 10 MBs of storage may be at risk. (I can envision one way that might work to fill the hard drive even for 5-MB-limited browsers, although I have no intention of testing it.) And, there are other potential and actual malicious uses of local storage. If things get out of hand, browsers will end up offering users tools to restrict local storage, just like they added cookie-restricting features once cookies were abused.
  • Local storage is not secure. The data is saved in unencrypted form. No sensitive data should be saved. Don't save someone's credit card info in local storage. If the device it is saved on is stolen or remotely hacked, the thief can find and read that info. The data is not even secure from a malicious user, who can use various tools to modify it. So, if you use a virtual currency for anything, don't locally store the user's currency total, or you'll soon find some users with massive funds. (You could try to use encryption to make the data more secure, but do you really want to go this route? A far better solution is to save sensitive data on the server where it is safer.)
  • Local storage is not bullet proof. Browser malfunctions potentially can affect it. Potentially? Make that actually. I've stored and retrieved data using local storage on a browser (Chrome v25.0.1364.152 m, in case you're wondering), which later crashed during the same testing session. On restart, the local storage data for the page was gone. No doubt other interesting things lurk for local storage with other browsers.
  • Local storage is "blocking." It's not asynchronous, so other operations are blocked when local storage is storing or retrieving data. For small amounts of data this usually shouldn't be an issue, but it might be with larger amounts of data. However, the HTML5 Web Workers feature provides a non-blocking way to use local storage.
• Session Storage
  If your browser has local storage, it also has session storage. Session storage is only persistent for a session: while the browser tab or window the page was loaded into is open. (While using the same window/tab, a user can navigate away from the page using session storage and later return without losing its session data.) Unlike local storage, session storage does not share data between two or more copies of your page that are running in different windows/tabs on the same browser. Session storage obviously is best used to store transitory state information. A number of documents claim that session storage is unlimited, but that is not true. Some web and mobile browsers allow unlimited session storage, but other only allow 2.5 or 5 MB. Opera Mini has no session storage (or local storage) ability.
  

  Test results will appear here if JavaScript is enabled.

• If you do have session storage, this next demo lets you enter text to be saved. Just fill out the fields as you like and click Save. You can see what you saved on the right. If you refresh the browser or navigate away from the page and then return, you'll see that your entries are persistent. If you close the window or tab of the page (or the entire browser itself) and then run the page in a new window or tab, you'll see that your entries are not saved. If you run this page in two windows or tabs of the browser, you'll see the session storage of one window/tab is separate from that of the other. Click Delete (or just close the window/tab/browser) when you want to get rid of the saved data.
  
  
  
  

  Your saved entries:

  •  
  •  
• Session storage has its own interesting quirks. For a site that requires logging in, it is possible that session data could be retained even after the user has logged out. For example, the user logs in to a page and does something that causes session data to be saved. The user then opens a second tab for the same page and later logs out in the second tab. How most websites (logically) implement this is that the user is now completely logged out, even on the first tab. However, the first tab by default still retains its session data. The web page itself would need to track what's going on and purge the session data from the first tab when the user logs out in the second tab.
• Session storage can also survive some browser restarts. After a crash, on restart some browsers attempt to restore the lost windows/tabs, and session storage is restored, too. This is in general a good feature, but it's something to be aware of.
• Session storage depends partly on human behavior. Some users leave their devices and browsers running for very long periods of time, so it is possible a single session can last for weeks or months. If you're extensively using session storage, how valuable is the stored data if the user only visits your site once a week or so? In these cases, your design may be improved by taking this into account.

Database Storage

• Client-based database storage would be a useful thing to have. Someday we'll have it in a form that all major browsers have implemented! I hope.
• Web SQL Storage is an SQL database API for web pages, but the specification was abandoned in 2010. Chrome, Opera, and Safari implemented it, but FireFox and Internet Explorer did not.
• IndexedDB (or Indexed Database, formerly WebSimpleDB) is a proposed web database API that Chrome, Firefox, and Internet Explorer (v10) have implemented, but other major browser have not (at least, not yet).
• Which to Use? Neither, yet, in my opinion, nor both. Between the two, almost all major web and mobile browsers are covered. However, Internet Explorer v9 and earlier has neither, so you will still miss the large installed base of IE8/9 users. (If you're only developing for a particular browser, than using its database API may be OK. Note, however, that Web SQL Storage implementations someday may be dropped by those browsers that have it.)

Offline API/Application Cache

• The Offline API allows a web page to function even when the page does not have an Internet connection. Well, more accurately, it allows a page to function if the Internet connection is lost after the page loads (more on this below). The Offline API allows the web page to control the application cache, which can have benefits even if the page/app never goes offline.
• The key to the Offline API/Application Cache is that the HTML source contains a link to a manifest that specifies what files are to be placed into the browser's application cache. The application cache is a bit different than a browser's general cache, as the application cache is more persistent. The browser will dump files from the general cache as it sees fit, and users can clear the general cache (or specify that it gets automatically cleared, such as on browser shut-down). Clearing the general cache does not affect the application cache. The user can choose to clear the application cache, too, but this is often harder to do. (Currently in Chrome, for example, you must enter chrome://appcache-internals/ in the address bar, press Enter or Return, and then individually clear each manifest listing. There's no Clear All ability in Chrome. Firefox, on the other hand, does list the application cache in Options->Advanced->Network (calling it "Offline Web Content") and does allow the entire application cache to be cleared in one click.)
• Browsers currently handle details about the application cache differently. For example, Chrome lets you save to the application cache by default, while Firefox by default prompts the user to give permission before files can be saved to the application cache. (Users can turn off this prompt in Options->Advanced->Network, but it is likely that the average user does not do this.) So, the application cache will be less used in Firefox, as some users will refuse permission when prompted.
• The memory limits for the application cache also vary between browsers per web page. Some allow "unlimited" storage (for Chrome, this means 2.2 GB; yes, gigabytes). Many mobile browsers only allow 5 MB per page, although at least some will prompt the user to increase the limit as needed.
• The Offline API is rather easy to use and simple to understand. You can specify what files are to be cached, what files are not to be cached at all, and what files (fallbacks) exist in two versions, one for online use and the other for offline use. Finally, it's extremely easy to tell the browser via the manifest that the application cache needs to be updated.
• So, what good is the application cache? Some uses are:
  • Online-offline Use. The "Offline API" is not perhaps a good name. It's more "online-offline": it's useful to allow pages that load online to continue to function offline if the Internet connection goes down. In other words, it's good for mobile browsers, where network connections can get dropped for all sorts of reasons.
  • Cache Control. Files you put into the application cache are persistent (much more so than in the general cache). The browser will preferentially use these files for your page, even when the page is online. So, you can use the application cache to store important, often-used files, and this will make your page load or respond much faster the next time the user visits it.
  • CSS File Control. Has this every happened to you? You revise your CSS file, test it out locally fine, upload it to your server, test it remotely, and the CSS changes don't show up. Yep, the browser is using the old version that's in the general cache. This can be a big problem if you don't have control over the server to set when the CSS file expires. You could do cache busting by giving the CSS file a new name every time you change it, but that's often impractical. You could append a bogus query string to the link (e.g., base_styles.css?v110313) each time you change the file, but that, too, can be impractical if you have a lot of links to maintain. Instead, you can put the file in the application cache by just updating one manifest file, which multiple pages can use.
• Now for the dark side:
  1. Internet Explorer v9 and under does not support the application cache. IE8 and IE9 still have significant market shares, so an application cache approach will fail to reach these users.
  2. Possible lagginess for first time users. When a browser navigates for the first time to a page that uses the application cache, all files to be cached are downloaded at the start of the session. This can be time consuming and may not be the best "first user experience" you want for your page. You can design around this (e.g., a non-caching version and a caching version), but that's more complexity.
  3. Possible lagginess when changing a cached file. If you update even only one caching file (and the manifest), all the caching files have to be downloaded again, as there's no way to specify which individual file needs to be downloaded again. This again can take time and annoy users.
  4. Browser requests. The fact that some browsers ask users to permit application caching means that you can't count on it being granted. Also, the request could annoy or scare some users, which is usually not good for your page. (This too can be designed around, by educating the user about this before having them hit with a storage request.)
• With all that, are you now ready for a demo?
  

  Use this link to see the Offline API Demo. Note: About 1.1 MB of files will be placed in the application cache when you go to this page.

And More!

• History API
  OK, some of the previous demos are a bit wordy. Here's a short one: the History API allows JavaScript to manipulate the browser history. The benefit of doing this is that you can use dynamic HTML to change how a page displays and yet the displayed URL and the history track these changes, so that the Back and Forward buttons behave usefully. OK, now the demo, which just detects if your browser supports the History API.
  

  If JavaScript is enabled, this box displays whether your browser supports the History API.

• Cross Document Messaging
  The same-origin policy helps prevent cross-site scripting attacks. However, it also prevents two different-origin documents from communicating directly even when each origin trusts the other. Cross document messaging allows a way for this to happen. In the following demo, the outer box is in one domain, the inner box is in another, and you can use the text field to send a message from the outer box to the inner one.
  

  Origin of the document in this page:  
• Since we're dealing with the web, cross document messaging is yet another instance where the major browsers don't work the same way. Internet Explorer, even version 10, only supports cross document messaging in iframes (and frames) but not between documents that are loaded in different IE tabs or windows. Also IE8, IE9, and Firefox v6 (and earlier) only support the passing of strings in the messages and not other types of data (like structured objects and JavaScript values).
• Channel Messaging
  Channel messaging is similar to cross document messaging, except that it allows two-way communication using pipes and ports. It is used for code (for example, JavaScript libraries) to communicate back and forth, and the pipes and ports allow a greater flexibility than does cross document messaging. However, no version of Firefox has yet implemented channel messaging, so no demo.
• Web Sockets
  The Web Sockets API is another two-way communication feature. It is used to establish a socket between a client and a server. The strength of Web Sockets is that, once the connection is set up, the server can initiate contact and send content to the client. On the web, which uses stateless HTTP/HTTPS, the client drives communications with the server: it sends a request to the server, which then responds. This is well suited for many tasks but is not well suited for other tasks, like chat. Various work-arounds exist using HTTP/HTTPS (like the client frequently polling the server to check if there's something to receive, or long polling, where the client contacts the server and keeps the connection open until the server has something to send). Web Sockets does the job better. (It accomplishes this by using a different set of protocols, WS and WSS, instead of HTTP and HTTPS.) While Web Sockets institutes two-way communications between a client and a server, multiple clients can connect to the same server. This easily allows, for example, chat: one client can send a message to the server, which then can push it to all connected clients.
• The Web Sockets API is implemented by the latest versions of the major web browsers and for iOS, but Android browsers do not yet support it. Also, it is only supported in IE10, so the many IE8/9 users can't utilize it. Previous versions of Safari (v5 web and v4/5 iOS) use an older, less-secure version of Web Sockets, and they may have disabled it by default for security concerns. Older browsers don't support Web Sockets at all. If you need to support a wide installed base of browsers, you will need to have fallback alternatives for these browsers.
• Unlike many "HTML5" technologies, you will also need to have some administrative control over your servers to set up a functioning Web Sockets system. If you use a hosting solution that provides you with little or no server administration, Web Sockets isn't practical for you. Unfortunately, this applies to the hosting service for this website, so there's no Web Sockets demo here.
• Geolocation API
  The Geolocation API is an opt-in way for browsers to attempt to geolocate the devices they are running on (and, typically, the user, who often is at the same location as the device). The "opt-in" part means that users must expressly give permission to be geolocated, and the browser cannot attempt to geolocate the user without explicit permission. Once permission is granted, the web page can consult Location Information Servers to attempt to locate the device. Location attempts use whatever is available and most accurate, from GPS (the most accurate, but not present in all devices), cell IDs for wireless devices, WiFi locations, and IP addresses (the least accurate but often good enough for many purposes).
• OK, now here's the first demo: whether or not your browser supports geolocation. (No permission is needed because no actual location information is being sought.)
  

  If JavaScript is enabled in your browser, this box will display whether your browser supports geolocation.

• In the following demo, the Geolocation API attempts to find your location when you use the button. (The first time you use the button, your browser will ask permission to geolocate you. Answer yes or no as you wish.) Wait, nothing happened? Many browsers will only use geolocation over secure HTTPS but over basic HTTP, which this website currently uses.
  

  Use Find Me to get your location.
• Geolocation is supported in all major web and mobile browsers (except Opera Mini, which deliberately doesn't support much). Older browsers, however, do not support geolocation: Chrome 23 (and earlier), Firefox 17, IE8, Opera 11, and Safari 4. Also, geolocation sometimes fails to work for the Windows version of Safari 5 (it just times out without getting location data). Many users are still using these older browsers, so the Geolocation API isn't a universal solution yet for geolocation.
• Web Workers—So the Web Can Walk and Chew Gum at the Same Time
  Under standard conditions, a browser can run only one JavaScript script at a time ("single threaded" in the jargon). Sometimes that's all you need, but there are occasions when it would be useful to run two or more scripts at once. JavaScript has some asynchronous abilities that help get around this limitation, but now the Web Workers API allows multiple scripts to run at once ("multithreaded"). You can create a worker for a specific script and communicate with the worker to run the script, exchange data with the script, terminate the script, etc.
• Web Workers can do a lot, but there's a few things they cannot touch: the DOM itself (as it's not "thread safe"—it can't handle two or more scripts simultanesously modifying it) and the window, document, and parent objects.
• Web Workers are heavy-duty hitters: there's a performance hit when a worker starts up, and there's a memory hit while a worker exists. Potentially, these hits can be significant, so it's advised to use Web Workers only when really needed. With that in mind, the demo only indicates if your browser can use Web Workers but does not try to use a worker for a task.
  

  If JavaScript is enabled in your browser, this box will display whether your browser supports Web Workers.

• Web Push Notifications—So Websites Can Push You Around
  The Web Push Notifications API lets a website send you notifications even if you are not on their page in your browser. If this sounds intrusive, it can be. Fortunately, you must first explicitly grant permission before a website can send you notifications. The website can then push notifications to you, with the operating system on your device getting involved to display them to you.
• Push notifications can be very useful for users in some cases, as for example it can them know that new content of interest is available. Push notifications can also be spammy. Some sites use them to try to get users to "rediscover" and "reengage with" the sites, without necessarily offering anything of interest to the users. Most users don't like being spammed, so ethical developers should only use notifications when they have a clear benefit for the users themselves.
• Old browsers and OSes do not support push notifications. Most modern browsers and OSes do. Does your browser support it?
  

  If JavaScript is enabled in your browser, this box will display whether your browser supports Web Push Notifications.

• One thing to remember about push notifications permissions is that they are based on specific browsers on specific devices. If, for example, a user grants permission for notifications in Firefox, no other browsers knows about this. If the user also uses Chrome, the user will have to explicitly grant permission on that browser as well. Similarly, if a user uses different devices, then the user will have to explicitly grant permission on each browser on each device. So, it's entirely possible that the user may have granted notifications permission for your website on some browsers and devices but denied them on others.
• Drag and Drop
  Drag and Drop is an HTML5 feature that adds... wait for it... native drag and drop support for web browsers. The usual caveats about partial support (IE9 and earlier) and bugs (Windows Safari v5.1 has a serious drag-and-drop defect) prevail. Overall, for the present, it may be better and easier to use a JavaScript library that supports drag and drop (like jQuery's UI plugin).
  

  If JavaScript is enabled in your browser, this box will display whether your browser supports HTML5 Drag and Drop.

• WebP
  WebP is an image format that supports both lossless and lossy compression, typically resulting in smaller file sizes than JPG or PNG can produce. WebP thus is of interest for web and mobile use, to minimize the content download time. WebP is developed by Google as an open-source project using the WebM permissive license. However, WebP at present is supported by only a few major browsers. So, unless you are willing to maintain and server two sets of images (WebP versions for supporting browsers and JPG/PNG for other browsers) or are willing to deal with the WebPJS JavaScript Library that enables WebP use for non-supporting browsers, it may be best to wait and see how established WebP becomes.