Loading blog entries.. loading


Blogs which referenced tag: [W3C]

 

Make your HTML5 Video support all browsers

 
Written by Wayne Ye  Monday, November 7, 2011

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:

 AndroidChromeFirefoxInternet ExploreriOSOperaSafari
Codec WinMacWinMacWin WinMacWinMac
MP4 or H.264 3.0 9 7 X X 9 3 X X 5 5
ogg/Theora 2.3 9 7 3.6 3.6 X X 10.63 10.63 X X
WebM 2.3 9 7 3.6 3.6 9 (withcomponents) X 10.63 10.63 X X

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»



Permalink:http://wayneye.com/Blog/Make-Your-HTML5-Video-Support-ALL-Browsers
Tag:

AJAX Cross-Origin HTTP request

 
Written by Wayne Ye  Friday, April 1, 2011

Background

Cross-Origin Request Sharing - CORS (A.K.A. Cross-Domain AJAX request) is an issue that most web developers might encounter, according to Same-Origin-Policy, browsers restrict client JavaScript in a security sandbox, usually JS cannot directly communicate with a remote server from a different domain. In the past developers created many tricky ways to achieve Cross-Domain resource request, most commonly using ways are:

  1. Use Flash/Silverlight or server side as a "proxy" to communicate with remote.
  2. JSON With Padding (JSONP).
  3. Embeds remote server in an iframe and communicate through fragment or window.name, refer here.

And so on..

Those tricky ways have more or less some issues, for example JSONP might result in security hole if developers simply "eval" it, and #3 above, although it works, both domains should build strict contract between each other, it neither flexible nor elegant IMHO:)

W3C had introduced Cross-Origin Resource Sharing (CORS) as a standard solution to provide a safe, flexible and a recommended standard way to solve this issue. 

Mechanism

From a high level we can simply deem CORS is a contract between client AJAX call from domain A and a page hosted on domain B, a tipical Cross-Origin request/response would be:

DomainA AJAX request headers

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

DomainB response headers

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

The blue parts I marked above were the kernal facts, "Origin" request header "indicates where the cross-origin request or preflight request originates from", the "Access-Control-Allow-Origin" response header indicates this page allows remote request from DomainA (if the value is * indicate allows remote requests from any domain).


View Post»



Permalink:http://wayneye.com/Blog/Ajax-Cross-Origin-HTTP-request
Tag:

HTML5 Web Storage in Essence

 
Written by Wayne Ye  Saturday, February 26, 2011

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)


View Post»



Permalink:http://wayneye.com/Blog/HTML5-Web-Storage-In-Essence
Tag: