Introduction

HTML5 video tag gave us the following advantages:

1. No plugin required, directly play.
2. Visible & controllable for Browser and search engine, not a "black box" such as Flash or SilverLight.
3. Cross-platform, in theory all PC/mobile browsers as well as Ipad/Windows 8/Android tablet PC. 
4. Downward compatibility. Which is very important, but W3C had made it simple and works, we can smoothly fall back to flash if the user agent does not recognize "<video>" tag.

So it is simple and pretty cool! However, there is still issues within a not short period: the browser support - each concrete browser and the company (ies) behind it supports different formant of videos, to be more specific, refer the table below stole from about.com:

So to support all browsers: IE 6.0+, Firefox, Chrome, Safari, Opera, etc, what should we do?

Cross All Browser Implementation

By searching on the google and half a day investigation, I found the solution, sample code pasted below:

 <video controls="controls" preload="auto" poster="napshot.png">
     <source src="My Video.mp4" type="video/mp4" />
     <source src="My Video.webm" type="video/webm" />
     <source src="My Video.ogv" type="video/ogg" />
     <!-- 
         Flash
     -->
 </video>

The code above results in IE 9.0+/Safari will load mp4, Chrome/Firefox and Opera will load webm, and IE 6.0 ~ 8.0 will load flash.

Note: as browsers may change its attitude on the video format support, so my code & comments might not right in the future.  

Few tips

View Post»

Background

Web Storage (also named Dom storage) is a brand new mechanism of storing temporary/permanent data introduced in HTML5 to replace cookie, it contains two new DOM objects: sessionStoragy and localStorage), in Web Storage Spec, Ian Hickson documented that Web Storage are intended to solve two cases that "not handled well by Cookie", they are:

1. The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.
   
2. The second storage mechanism is designed for storage that spans multiple windows, and lasts beyond the current session. In particular, Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the client side for performance reasons.

sessionStorage and localStorage are introduced by W3 in HTML5 to solve problems above, let's begin with a review of how Cookie currently works.

Current HTTP State Storage – Cookie

Mechanism

An HTTP Cookie was a set of key/value pairs which an HTTP web server requests a concrete client browser (i.e. User Agent - UA) to store on client's hard disk, when the UA request to the web server further, UA will wrap all the cookie data within the HTTP request header as long as following conditions are all satisfied:

1. The cookie data has not expired.
2. The requested domain is under exactly the same domain when cookie was stored.
3. The requested path under the domain is the same one where cookie was stored.

Once the cookie expires, browser will delete it from local hard disk.

A common cookie example:

1. An end user types www.foo.net in a browser's navigation bar and hit enter.
2. www.foo.net returns HTTP status 200 message below (In the Green part, web server expected client browser to store two Cookie key/value pairs: WayneKey1=value1;WayneKey2=Value2, they could be accessible from the entire domain, and they will expire after 1 year):
   

   HTTP/1.1 200 OK
   Content-type: text/html
   Set-Cookie: WayneKey1=value1;WayneKey2=Value2;domain=www.foo.net; expires=Tue, 24-Feb-2012 07:13:22 GMT; path=/; HttpOnly
    
   (Response HTTP body)