The truth about Google and H.264

 If you leave this post remembering only one thing, let it be this: Making something Open Source does not automatically make it better, it just makes it Open Source. How's that for flamebait?

Unless you have been living in a box buried underground lately, you have probably noticed the shitstorm surrounding Googles decision to drop support for the H.264 codec in it's Chrome web-browser. Of course, as a web-developer I do indeed have some thoughts on why this happened and whether it's a smart move. However, before sharing from my goldmine of biased opinion we'll need to get the REAL facts straight, so you can judge for yourself.

Open vs. Free

H.264 is a codec constructed from a bunch of patented technologies and it's developed by the «Video Coding Experts Group» and the «MPEG Group». H.264 is a video standard (ISO/IEC 14496-10) handled by the «International Organization for Standardization». H.264 is an open standard, however it is not a free standard. All the patents included in H.264 are handled by MPEG-LA, not to be confused with the MPEG Group. Microsoft and Apple are some of the minor patent holders of H.264. H.264 is free to use for non-commercial usage, for end users for it's lifetime. For commercial usage (e.g. iTunes Store) and for usage in decoders (e.g. in browsers) one will have to pay a license fee capped at $6.5M. H.264 sports a bunch of hardware decoders, from iOS devices to Televisions and DVD/BlueRay players. To create H.264 files you can use everything from Apple QuickTime to FFMPEG. H.264 is supported by Apple Safari, Internet Explorer 9 and Google Chrome via the Mpeg4 container.

VP8, the codec within the WebM container, was developed as a proprietary product by a company called On2 Technologies. In 2010 On2 Technologies was acquired by Google, whom continued to release the patents within VP8 under a Creative Commons License. VP8 is free to use and free to implement. As of today there are slim to none hardware support for VP8 decoding. To decode/encode VP8 today you'll most likely use Google own software based «libvpx» library or the FFMPEG(ffvp8) implementation. VP8 is today supported by Opera and Firefox 4 via the WebM container.

The thing to notice here is that H.264 is indeed an open standard, developed by an independent companies and approved as a standard by ISO, but it's not free to implement. VP8 was developed as a proprietary product by one company, later released into the public domain as Open Source. VP8 is free to implement.

What does it all mean?
In my opinion Googles move has nothing to do with being open, it might have something to do with being free however. For companies like Mozilla, which develops a truly Open Source product it totally makes sense to not implement a video codec for which you have to pay patent royalties. Note that Mozilla does not support MP3 either, which also contains commercial patents. It's not that Mozilla can't pay the license fees, it is more the fact that you cannot freely distribute as Open Source a product which implements a patent encumbered video decoder. Mozilla (Firefox) has never had support for H.264, which is a decision I completely support on the basis of their completely open approach in other areas of the implementation as well.
Google on the other hand made the rather strange decision to remove it's already existing support for a widely used codec in a browser littered with other patented technologies. Under the flag of being "open". It's this "being open" part which rubs me the wrong way. Google Chrome is NOT an open browser in the same sense as Firefox is, it implements mp3 and it's own embedded FlashPlayer to mention a few things. As far as I can see, the only logical explanation for Googles move is that this is a business decision. They don't want to pay for a license partly under the control of Apple and Microsoft and would rather control their own codec, namely VP8, which is under Googles control, even if it's Open Source. VP8 has never been through any independent standards organization like H.264 has, it was developed as a proprietary product, in sharp contrast to the independent development of H.264 which was a joint operation shared by many companies. Codec developers also claim the superiority in quality of H.264 over VP8. It's estimated that about 60-70% of all web video is encoded in H.264 already, a large part of that is YouTube owned by Google. The reason you can watch video for hours on your Android. Microsoft or iOS device is the H.264 hardware encoder which sits inside of it. Despite all of this Google chooses to exclude H.264 from it's web-browser.. to be open.. yea right!

Graceful degradation vs. Progressive enhancement

There are three possible things you might be feeling after seeing that header. (1) No interest at all (confused?), (2) somewhat intrigued and curious (and confused?) or (3) already in the trenches ready to defend your position.

First of all, I know that this is somewhat of a "controversial" area, but in the end you do not need to agree with what I have to say, it's just my point of view. But, before we get to the subjective part, let's take an objective look at what is involved when considering these two approaches to (in this case) making web-applications.

Graceful degradation (or fault-tolerant system).
In web design, this is the basic idea that we design and write code for the most capable browsers first, then we add support for less capable browsers. An example of this is the "alt" attribute of the «img» tag. Most users will get the image, while those that browsers that do not support (or choose not to display) images gets the "degraded" text representation. The «noscript» tag is another example.

Progressive enhancement.
When subscribing to «progressive enhancement», you will first design and write code for the least capable browsers (like Internet Explorer). Then you'll add in functionality to enhance the experience for users with more capable browsers (like Opera, Firefox, Chrome and Safari). The linked stylesheet is a much used example of this. First you create the web-app in pure HTML (works almost everywhere), then you link a stylesheet to the page (which is ignored by old browsers), making the experience better for more up to date users. The FlashPlugin based «SIFR» method is also an example of «progressive enhancement». 

Aren't those two identical (or the subjective part)?
Both of these practices will lead to the same result in most cases. That is, the goal of both approaches is to give the best user experience no matter what browser might be trying to display the web-application. The difference is the starting point. Where as «progressive enhancement» assumes the lowest common denominator as a starting point, «graceful degradation» assumes the opposite, starting at the newest and adding in support for less capable browsers later.

It is my opinion that the starting point of the lowest common denominator is a not such a good idea, because this line of thought will slow down the progress of new technology adaptation, especially within large enterprise environments. I don't think people in general will catch up on anything unless there is an incentive to do so. A "degraded" experience is a great incentive. Also, web-developers should in my opinion be allowed to adapt new technology as early as possible. A bunch of pig headed Internet Explorer users should not stand in the way of that. There is also the issue of security, speed and support for assistive devices. I would highly recommend the online book "20 things I have learned about browsers and the Internet" from the Google Chrome team, where you can read about why up to date browsers are important for the Internet itself.

I know what you are thinking. "Wouldn't both approaches allow for rapid technology adaptation?". The answer is of course yes...and no. You can use «progressive enhancement» and still push the limits of technology, forcing the world forward. However, to put it bluntly, that is not the intention of this approach, it's intention is to first support the slackers, then new technology. «Graceful degradation» aims at first supporting new technology, then give the slackers the content, but with a lesser experience. There's a subtle, but important difference here.

Note that «graceful degradation» has it's drawbacks as well. It is somewhat more complicated to add in "old technology" to a "new technology" project, rather than building "new technology" on top of "old technology" like «progressive enhancement» does it. But, as time goes by, a «progressive enhancement» approach will have more and more of it's foundation deprecated, while the root building blocks of a «graceful degradation» based project will become more and more relevant.

Web-apps vs Native-apps

There is a world, a nerdy world occupied by people living in a private bubble called "IT". In this world "new" things are created, things that "ordinary" people couldn't care less about until they are publicized and popularized. Things like Facebook, Twitter, the iPad, gMail, the AppStore and the Internet are things created by the people in this nerdy world. Right now an imagined war is raging in this world, a war between the "by god we will cram everything into a browser" people and the "browsers are cool but slow" people. I'm of course talking about web-apps vs native-apps, or Google vs Apple as some have come to believe. So, is there a war? And who's winning?

When contemplating the differences inherently present in the not so wide crevasse between web-apps and native apps there are four main areas I want to examine:

1. Performance
2. Accessibility
3. Data persistence and security
4. The browser

Performance

The first thing that springs to mind when taking the classical approach to this age long tiresome debate is the issue of performance. Native apps perform better than web-apps, hence the end user gets a smoother and better experience when using the app. This is true, in most cases. However, performance is more than just the smoothness of animations and the speed of which data is read. Consider the process of installing Adobe Photoshop on your trusty Windows laptop, then activating it, then figuring out how to navigate the god awful interface just to adjust the contrast of an image. Compare that workflow to opening the image with Picnik and the choice is pretty clear. Web-apps rule! But, wait. What if you want to edit the movie you shot during the holiday with your FlipMino HD, can you do that in a web-app? Well, sort of, with services like JayCut and the likes. However, you will get a much better result using iMovie, which is already on you Mac. What about Skype, code compiling, 3D games and so on..? To make a long story short, native apps will outperform web-apps when it comes to pure performance and as long as web-apps are based on a document oriented language (HTML). It will always be a catchup game for web-apps. But, web-apps have another kind of performance advantage, accessibility.

Accessibility

A web-app is always up to date, most of them are easy to use, requires no installation and can be used from almost any computer. That is, except when you're not connected to a network. A statement with modifications indeed, some web-apps do work when in offline mode as well, however a pure offline web-app would be pretty pointless. Consider Google Docs versus Microsoft Office. If you're an author (a brave one) you might want to use MS Word, or if you need some crazy ass pivot tables or other super advanced stuff you would perhaps also need MS Excel. However if you just want to calculate stuff, create and produce formatted text, spreadsheets and presentations, Google Docs is far superior to MS Office. Oh, have you tried to collaborate in real time on a MS Word document, doesn't work does it?! Also, Google Docs keeps your documents on the server so you can access them from anywhere and they are always backed up. Does it work offline, well, not yet.

Data persistence and security

With a native-app your data is always available to you, online or offline, provided that your computer is with you of course, or that you have synced the data to the cloud. What happens if (God forbid) your house (containing your laptop) is leveled by aliens? Where did all your native-app data go? It's history! Your e-mail and Google Docs data is safe at Google. That is, if you are okay with Google searching through your e-mails and documents in order to give you targeted advertisements? And what happens if, say you have saved all your links and bookmarks at a cloud service (lets call it Delicious) and then out of the blue Yahoo! suddenly decides to fire all the people working at that service and let it die a slow death. What about all those years worth of bookmarks then? This is somewhat complicated isn't it?

The browser

How awesome do you think it would be to play Halo: Reach in Google Chrome? Not so much? What about programming a movie-editor that has to work within the browser sandbox and is only allowed to cache 10MB of data, how would that go down you think? It wouldn't you say? Last one: Let's say we want to persuade ReSpawn Studios or Epic Games to work with WebGL on an unknown amount of browsers and computers instead of writing their engines based directly on a familiar platform. No dice? This is because the browser isn't a gaming platform, it isn't a good platform for handling a lots of files or large files. But, it does add another layer of security and it make everything accessible everywhere, plus if you're using Facebook and gMail what more do you need.. The average time a user spends in a web-page is about 10 seconds, this makes the "browser experience" kinda ..volatile..and short lived. Native app sessions are more persistent and have a longer lifespan, hence more suitable for playing games, editing movies and so on. The browser can do many things, not everything and yes, native apps will continue to be perform better for some time.

There is no war. The browser with it's web-apps is an awesome platform for some things, just as native apps do better on other things. I for one enjoy both web-apps and native-apps and will continue to do so for a long time I suspect.

Scrolling a div on multitouch devices using JavaScript

With the emergence of touch devices and the slow but steady tendency of replacing the mouse as an input device, this leaves us with fingers. Both the iOS platform and the Android platform sports APIs for dealing with touches from fingers, for native apps that is. But what about web-apps? Enter the JavaScript touch DOM events. In this post I'll discuss how to use the touch events to scroll a container (a div) using a finger, e.g. on an iPhone.

What you'll need
First of all you need a touch device or a simulator like the iPhone simulator to test your code. The code itself can be written in any text editor, however it is recommended to use an editor with a build in debugger or a test environment that supports debugging JavaScript touch events. You might be thinking that Firebug or Drosera is great for debugging, but how exactly would you trigger the touch events in your desktop browser? Well, you can't. This is why I'm using Dashcode from the iOS SDK for my JavaScript coding. More on using Dashcode in a later post.
Note that this code is written for WebKit based browsers, but should work in principle on other touch browsers as well.

The HTML

<div id="holder">
   <div class="content">
       your content here
   </div>
</div>


Notice that the content is inside of a div within the holder div, this is because you can't scroll the div in which the touch event is attached to.

The CSS

#holder{
   width: 300px;
   height: 200px;
   background-color: blue;
   -webkit-box-shadow: 3px 3px 5px #000;
   padding: 10px;
}

#holder div{
    width:100%;
    height:100%;
    color: white;
    overflow: auto;
    -webkit-user-select: none;
}

Not much revolutionary here, but do note that we set the "overflow" property to auto on the content div, not the holder itself. Also, we set the "-webkit-user-select" to "none" on the content div, thereby preventing the user of selecting the content. This is optional.

The JavaScript
There are three main touch events:

• touchstart - Called when a finger touches the listening container (finger down)
• touchmove - Called repeatedly when a finger moves (finger down and moving)
• touchend - Called when a finger leaves the listening container (finger up)

Each of these methods gives us an event with a touches array. Remember, there might be more than one finger since these APIs are made to handle multitouch devices. To get a hold of the vertical position of one finger you would query the touches array for one finger and get it's pageY property, like this: event.touches[0].pageY

From this we can calculate and set the scrollTop property of the content container. But, wait! If you try this the rest of the page will also scroll, not what we wanted. The reason why this happens is because the touch event bubbles all the way up to the window, making the browser think it needs to scroll the window because you have dragged your finger on it. We need to tell the event to stop bubbling, we will handle the event ourselves. We do this by calling: event.preventDefault()

The complete JavaScript code will then look something like this:

var startPos;
function init()
{
    var scrollArea = document.getElementById('holder');
    scrollArea.addEventListener('touchstart', function(event){
        touchstartHandler(event);
    }, false);

    scrollArea.addEventListener('touchmove', function(event){
        touchmoveHandler(event);
    }, false);

    scrollArea.addEventListener('touchend', function(event){
        touchendHandler(event);
    }, false);
}

function touchstartHandler(e)
{
    startPos = e.touches[0].pageY;
}

function touchmoveHandler(e)
{
    var touch = e.touches[0];
    var targetBox = e.currentTarget.getElementsByTagName("div")[0];
    e.preventDefault();

    var fingerMoved = startPos - touch.pageY;
    startPos = touch.pageY;

   targetBox.scrollTop = targetBox.scrollTop + fingerMoved;

}
This is just a simple example, but it's something you'll probably end up using a lot. Speaking of...

When should you override the default window scroll
On an iPhone there is not as much need for this method as you'll probably scroll the entire screen in most cases anyway. However, the iPad is a different story. Take a look at the iPad version of gMail created by Google. They are using this method with success, and they have added inertia scrolling as well. This can be accomplished using the last touch event we did not implement, touchend. Maybe more on this in a later post. Anyway, you should use you own scrolling when it's appropriate to scroll only a part of the app, like a spilt view list or something like that.