Problem

I recently came across a small problem. When trying to get a movie (using the html5 video tag ofcourse) I found out that the iPhone doesn't play movies larger than 640 x 480 pixels and with a base profile other than H.264. Don't believe me, but look at their page.

As the client really wanted his rather large movie on the page and did not wanted it to be scaled down a notch, I was presented with a challenge. He also really wanted it to work on his beloved iPhone... What is a guy to do?

Solution

After some time I came up with a solution and a rather simple one it is. I use the rather excellent html5media script to get it to work in browsers without support for the video tag and want it to work in as many browsers as possible. So I already have two different sources in my video tag.

Like this:

<video
	poster="pathto/poster.png"
	width="780"
	height="470"
	controls
	preload>
	<source
		src="pathto/movie.ogv"
		type='video/ogg; codecs="theora, vorbis"'></source>
	<source
		src="pathto/movie.mp4"
		type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'></source>
</video>

As the movie I tried to play was to big, the iPhone didn't wanted to play it. Turned out all I had to do was include a third source into the video tag, pointing to a iPhone specific file, like this:

<video
  poster="pathto/poster.png"
  width="780"
  height="470"
  controls
  preload>
  <source
    src="pathto/movie.ogv"
    type='video/ogg; codecs="theora, vorbis"'></source>
  <source
    src="pathto/movie.mp4"
    type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'></source>
  <source src="pathto/movie.m4v"
    type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'></source>
</video>

Here you go, a solution to play large video's on your website, without compromising the quality for the desktop and still get it to work on the iPhone...

I hope this will help someone and if you have a better solution, please let me know...

Links

Some stuff I used to get the whole video she-bang working:

camendesign

This got me started

html5media

And this is what I use now to get it to work.

bing.com is the new search engine of microsoft. It could be great with the amount of smart people at Microsoft and the amount of money thrown at it. The search results are what you expect from any decent engine (a search for wnas puts me on top). But what got me baffled is the markup of the page, which comes in at a hefty 26,708 bytes. And that for a page which has one input field and some links... Me as a front end developer, I'm baffled by that size and kinda insulted. I have to wait longer because they used front page or what ever, no way, not in 2009 I don't.

The real fun comes when you do a certain magic trick called view source. Most of the size of the HTML is being formed by inline css and javascript. There even is a table in there, along with inline script handlers...

1999 called and it want's it's markup back, guys.

The numbers

Still I get back to the size of the page, a whopping 26,708 bytes with all the bells and whistles. If you strip the javascript alone, you're still left with just 13,462 bytes.

Thats 13,246 bytes of inline javascript for you.

So no javascript solves the size and the waiting time? Not quite, we have inline css too. So if we get rid of that, we are left with 5,524 bytes.

So the css alone is 7,722 bytes.

It seems that were getting there, no. No way, the html is very much too much and can be optimised to I think half of it's current size.

That size being 5,524 bytes for HTML alone.

If they got the correct markup and got their CSS and JavaScript from external sources, the user would only had to download that once. And would get a better experience, because faster is better.

Conclusion

I think that the front end of this page was build by a .net developer, who thinks everybody got a broad band connection. Maybe that is the case, but I know that my patience is less now than it was when I had a 14k4 modem. If I have to wait, even for a few seconds, it's not my fault and the chance that I navigate away from that page would be greater now than it was back in the 14k4 days.

So Microsoft, please clean up your act and hire a decent front end developer. Maybe you could look at this awesome presentation from Nicole Sullivan at yahoo. It shows you how much speed matters.

After years of domination, finally IE's share is starting to slide down to a respectable level. Web developers rejoice! Go and read for your self here:

Internet Explorer's progressive slide continues: Microsoft's browser is down to 66.10 percent from 73.01 percent a year ago. Half of that loss has been taken up by Firefox (up from 19.03 to 22.48 percent), with Safari also benefiting (up from 6.31 to 8.21 percent).

See the source

And as for mobile, it seems even better for us:

If the breakdown is restricted to mobile platforms, the shares are (to the nearest whole number) iPhone/iPod touch 65 percent, Android 9 percent, Java ME 8 percent, Symbian 7 percent, Windows Mobile 6 percent, BlackBerry 3 percent, others 2 percent.

See the source

But as a word of warning, this may look good. But in my opinion we still have to cater some content to IE6 users, as each user is as important as the others. It just mean that we will have to jump through less hoops, as hopefully customers will be using a better browser than IE6.

As I have just upgraded my blog from wordpress to habari, I am now faced with a really nice gray skin called 'charcoal'. If you know me, you must know that this out of the box style is not my thing. So I am going for a redesign and will build a new theme as I am at it. The redesign will NOT be visible on this page, but you can follow it on habari.wnas.nl.

This is a clone of this site, as it uses the same database and stuff. In doing this I can work with real data, no lorum ipsum for me please and I won't bother you, the reader, with unnecessary breakage and stuff.

Be warned that I will not try to make the site look the same in every browser, in the end a user with ie6 or below should be able to read everything. But the really nice things will be done with css3 selectors and so on.

I short I will be pulling an andy on you. I will not be slowed down by the lowest common denominator. So for now peek behind the vail and please comment if you see anything you like...

I write a lot of javascript in my present project. Doing this, I just love firebug and more to the point the console.log function that it lets me use. Bummer is only that it doesn't work in IE, the one browser that needs javascript debugging most. It also throws javascript error in IE when used. That is something that can be avoided by cleanly remove all of those console.log statements before you send stuff to be tested.

But, as everybody knows in the real world people tend to forget such things. So in annoyance with these errors, I set out to recreate the basis console.log function for IE as well. In retrospect it turns out that I set out to create a better mouse trap, but hey, it was fun and good enough to share, so lets...

In my solution and do not worry, I will share other solutions but first I will speak my mind. The console.log function is not used, instead you use logger(message). This sends the message to message to the console, if there is any, or it creates an ul (with an id of 'logger') in which it sets li's with the individual messages. So without further ado, I present to you the code:

 /*
 * wilfred nas
 *
 * info@wnas.nl
 * http://www.wnas.nl/
 * http://snippets.wnas.nl/
 */

// to intitialize the logger set : var log = 'true';
// change to 'false' to remove logging statements from you app.
// or (better) remove all logger statements from your code.
var log = 'true';
//var log = 'false';
/*
 * the logger functionality is a attempt to recreate some of the console functions of
 * fire bug for IE, the browser where you need js debugging tools the most. *
 * to use it you replace console.log(msg) with logger(msg), this sends the msg to the console or
 * it creates an ul to receive your (LIst of) messages...
 */
/*
 * works in  safari 2, opera 9, camino, webkit, ie 6 and firefox 2 (with or without firebug).
 */
function logger (msg){
    if (log == 'true'){
        // first we need to do some browser sniffing, look below for the explanation.
        var b = navigator.userAgent.toLowerCase();
safari = /webkit/.test(b);
        /*
             we only sniff what we need...
            opera = /opera/.test(b);
            msie = /msie/.test(b) && !/opera/.test(b);
            mozilla = /mozilla/.test(b) && !/(compatible|webkit)/.test(b);
        */
// bummer, safari seems to think that it has a console, so we make sure that it goes through.
        if (window.console && !safari){
                console.log(msg);
            }
        else {
            if(!document.getElementById('logger')){
                var ul = document.createElement('ul');
                ul.id = 'logger';
                document.getElementsByTagName('body')[0].appendChild(ul);
            }
            var ul = document.getElementById('logger');
            var li = document.createElement('li');
            ul.insertBefore(li,ul.firstChild);
            li.innerHTML = msg;
        }
    }
}

I think that it is a nice solution to a real problem, if you want see my solution here. If you want to try other people's solutions, go and seek googles advice. Something that I should have done before writing my own stuff, but at least it helps me understand javascript a bit better. Something that is always good I think.

My advice to you is, either use my solution (and if you do, please let me know, I will be proud) or go and use faux console by Christian Heilman's. I think his is better javascript, as is to be expected...

The downside is that he wrote it to be included as a seperate piece of javascript and it still needs to have all of the console.log statements removed for the live code. Where as in my logger, all you have to do is change var log == 'true' to false to go live. I think that this is a strong point, in my situation where I deliver stuff to be tested in two day cycles, as it goes faster.