I’ve no idea how the web video format war will end. My preference is that a free, non-patent encumbered, high-quality video codec will become the standard, and WebM is the best fit for that description. Despite the recent announcement by the MPEG LA, the patent pool which controls licensing of H.264, that it will always be free for ‘video delivered to the internet without charge’, that still doesn’t make it free-as-in-speech, and still not free-as-in-beer for anyone wanting to build a business around video encoding/decoding (which includes, if I’m not mistaken, bundling it with a browser). All that said, my preference is meaningless in the face of so many vested business interests.

But this post isn’t really about that; it’s about clearing up a misconception. One common statement I keep seeing repeated (WebMonkey said this in May, but I’ve seen it even more recently) is that Safari will be the only browser to not support WebM, when even the Internet Explorer team have promised to. That’s not the case. What the IE team said was that they will support WebM (or rather, the VP8 codec) as long as the user has installed the codec on Windows. Safari’s position is identical, they just haven’t publicly stated so.

The current free alternative to H.264, OGG video, is also not supported in Safari — but you can play OGG videos in Safari by downloading and installing the Xiph Quicktime Components. Likewise, Windows Media files are supported through Flip4Mac. WebM can be supported in Safari in the same way, as soon as someone creates a QuickTime plugin (I believe experimental support is in Perian already). This is exactly the same situation as with IE.

Where this doesn’t apply is on mobile devices; many — principal amongst them, the iOS range — don’t allow extra codecs to be installed. However, this is slightly supplemental to my point, which is that both IE and Safari — on desktop — are capable of playing WebM via a plugin. I believe that if people will install the Flash plugin, they will install the WebM plugin — and when we have choice and competition, a true standard can be reached by consensus, rather than financial clout.

Firefox do a great job of this with their website The Burning Edge, which gives fortnightly (more or less) lists of changes in the latest trunk builds, and Opera’s Desktop Team Blog does likewise on a semi-regular basis. The Internet Explorer team have done a good job of documenting all the changes in IE9 with the Platform Preview Release Notes.

The notable exception seems to be WebKit. I’ve looked around but I can’t find any site which gives an overview of changes in the nightly builds. I could subscribe to the RSS feed of their Trac, but it would be a nightmare trying to find the interesting features amongst all the technical changes. The Surfin’ Safari and Planet WebKit aren’t any help.

So does anyone know how to find this information for WebKit? I can’t believe it doesn’t exist.

Update: As if by magic, look what I found just a day later: Last week in.. WebKit and Chromium!

Now, there are loads of blog and forum posts which give differing advice on presets and parameters, and I’m no expert — so what I’ll do is just show you two quick ways that worked for me (I have a Samsung Galaxy S).

A couple of things to note: this post refers specifically to video embedded in web pages with the video element, so the other two requirements from my previous blog post still stand; also, the methods shown below should mean your videos play on iOS too, so you don’t have to encode for different platforms.

The first is cross-platform, using Handbrake. What I did with this was to use the iPhone & iPod Touch preset, check the Web Optimized option, and change the Average bitrate option (in the Quality section) to ~1000kbps (you should then save this as a new preset called Android).

You’ll also need to change the size of the output video in the Picture Settings options — I changed mine to 480 wide (keeping the aspect ratio) and they came out really crisp and sharp. You can see the result of that below (if your browser supports it).

The second method is also cross-platform, and uses VLC (I’m using version 1.1.1, not sure if older versions work the same). It involves more set-up the first time around, but will be easier with each subsequent conversion. Update: I was using VLC for Linux, but the OSX version seems to be quite different.

Go to Media > Convert/Save, add the file to be converted, and choose Convert from the selection at the bottom. Name your Destination File [filename].mp4, and from the Profile list choose Video — H.264 + AAC (TS).

Hit the Edit icon next to the list, and go through each tab in turn; in Encapsulation choose MP4/MOV; in Video Codec un-check the Keep original video track box, choose H-264 from the Codec list, empty the Scale field and enter a value in Width (I used 480); in Audio un-check the Keep original audio track box and select MPEG4 Audio (AAC) from the Codec list. Now click Save, and all of these settings will be remembered so you don’t have to enter them again.

With all that done, hit Start to encode your video. You can see the result of the VLC encoding below. Update: This video doesn’t seem to play on iOS.

The third method is the simplest, but works on Mac OSX 10.6 only. Open up your source video in Quicktime, then go to File > Save As. Choose iPhone from the Format selector. You get less control over your output with this — the width is always 480 and the bitrate is calculated automatically — but it works without fuss. The output of this method is shown below.

A slightly more convoluted method is to use DoubleTwist, which performs on-the-fly conversion. Connect your Android device, then transfer your video to it — the optimum parameters will be automatically selected. When complete, copy the file back from the device to your computer. (I haven’t actually tried this myself).

I’ve read that you can use WinFF, although I haven’t been able to make this work so far.

I’ll keep this post updated as I discover different methods, and do feel free to let me know in the comments what works for you.

From what I can tell, there are three requirements for video to work in Android browsers:

1. You must not use the type attribute when calling the video
2. You must manually call the play() method using JavaScript
3. The video must be encoded as .m4v, not .mp4 Update: This is not correct (see below)

Update: This may be a specific encoding issue rather than all .mp4s; some .mp4 videos seem to play with no problems, others do not. Further update: The video type was a red herring; see my follow-up post, Encoding Video for Android, for more about this.

You can see this working in the demo attached to an older post of mine: Demo: HTML5 Video Controls With JavaScript. This works, AFAIK, in Android, iPhone and all video-enabled desktop browsers. The markup I’ve used is:

<video id="video" autobuffer height="240" width="360">
<source src="BigBuck.m4v">
<source src="BigBuck.webm" type="video/webm">
<source src="BigBuck.theora.ogv" type="video/ogg">
</video>

The first source element calls the video in .m4v format, without specifying the MIME type in the type attribute; I’ve tried both video/mp4 and video/x-m4v, and neither works. Omitting the type attribute altogether lets the video play, and seems to have no ill-effect on other browsers which play the .m4v file.

In order to play the video in Android, I also have an event listener in the JavaScript which plays the video when the element is clicked on, somewhat like this:

var video = document.getElementById('video');
video.addEventListener('click',function(){
  document.play();
},false);

I tested this on my own phone and an HTC Desire, and it works just fine on both. Hope this is of help to someone.

* It’s a Samsung Galaxy S, and I’m delighted by it.

The drawback of this is that it’s not ready for use just yet—browsers that don’t support SVG in background-image will not provide any fallback, even if you supply another background-image value; so in non-supporting browsers, no image at all will be displayed.

This was annoying me a little, and I couldn’t find any workarounds that didn’t use JavaScript. However, after a bit of head-scratching I’ve come up with a way to get around it.

In order to have browsers which don’t support SVG display a PNG image instead, you should use this code:

E {
background-image:  url('image.png');
background-image:  none,url('image.svg'), url('image.png');
background-size: 100% 100%;
}

Browsers which support SVG and multiple backgrounds will show the SVG; browsers which don’t support SVG will fall back to the PNG in the background-image stack. As far as I know, all browsers which support SVG also support multiple backgrounds; any which don’t (i.e. IE) will fall back to the PNG in the first background-image declaration.

Update: Thanks to a comment I have amended this technique. IE was not falling back to the first background-image as it should have done, but I got around this by adding a none value in the declaration. This invalidates the rule in IE and forces the fallback to the previous declaration.

You can see a demonstration of it here: Background SVG with PNG fallback — demo.

This technique is not without its own caveats, however. First and foremost, the SVG must not have a transparent background, or else the PNG in the background layer below it will probably show through. Also, depending on how fast the SVG file loads, the PNG file may show up first and then be covered over.

Finally, if you’re using the same background image at different sizes and either your browser doesn’t support background-size or you don’t want automatically resized PNGs, you’ll have to use the rule for each instance:

E {
background-image:  url('image-small.png');
background-image:  none,url('image.svg'), url('image-small.png');
background-size: 100% 100%;
}

F {
background-image:  url('image-large.png');
background-image:  none,url('image.svg'), url('image-large.png');
background-size: 100% 100%;
}

And of course, if you’re creating multiple PNG images anyway, you may feel there’s not a lot of point in using SVG images as well. I’ll be the first to admit that this isn’t a completely bulletproof technique, but I offer it in the hope that in certain circumstances it could be useful.

You can now use SVG with the img element, as well as the background image in CSS.

I know you can already use SVG in background-image with Safari, Chrome and Opera, and this, coupled with Internet Explorer’s push towards SVG and the strong chance this will be available in IE9, made me decide to take a closer look.

I’ve put together a little demo page which you can view with Safari, Chrome or Opera — ironically, this doesn’t seem to be implemented in Firefox nightlies at the time of writing:

SVG in background-image demo

The same image is used many times at different sizes on this page, displaying the grand advantage of SVG over PNG: it can be resized without the same loss of quality that bitmap images suffer.

Implementation is very easy:

E { background-image: url('image.svg'); }

If you’re looking at the demo in a WebKit browser, you’ll notice an empty box labelled ‘SVGZ’ — the background-image on this element is in the compressed SVG format, SVGZ, which only Opera supports:

E { background-image: url('image.svgz'); }

The file size is less than one-third of the non-compressed version.

The drawback of this is that it’s not ready for use just yet — browsers that don’t support SVG in background-image will not provide any fallback, even if you supply another background-image value; so in non-supporting browsers, no image at all will be displayed.

Update: I’ve found a technique for using SVG images with PNG fallback.

The image used in this demo is from All Free Vectors.

In the article I explain how to build a dynamic Contact area, as we did on our recent redesign of Preloaded.com, using the Web Storage API and the BBC’s Glow Javascript library.

I’m not sure what the rights situation is with this article, but I hope that at some point in the future I’ll be able to post it here on my blog. But in the meantime, you can buy a copy of Net magazine in the UK at all good newsagents, as the saying goes (I don’t know if it will be in overseas editions also).

On the subject of print, I’m also currently writing a book about CSS3 which should be published later this year. I’ll have more information on that nearer the time.

If you have a nightly build of Firefox you can see a little demo I’ve put together of them in action.

The first new property is –moz-calc, which is the experimental implementation of CSS3’s calc function. This allows you to perform simple mathematical functions on length values.

Take a look at the demo, where you’ll see two h2 elements; both have the same styles applied to them, but the second also has some extra calc values for some of its properties:

font-size: -moz-calc(120% * 3);
letter-spacing: -moz-calc(0 + 2px);
text-shadow: rgba(0,0,0,0.33) -moz-calc(4px / 2) -moz-calc(4px / 2);
word-spacing: -moz-calc(0.75em - 0.25em);

The font-size property has a value of 120% * 3, or 360%; the letter-spacing property has a value of 0 + 2px, or 2px; the text-shadow property has x and y offset values of 4px / 2, or 2px; and the word-spacing property has a value of 0.75em — 0.25em, or 0.5em.

The values themselves are abitrary and not important; what matters is that we’re doing calculations in CSS!

At the moment the only properties which support –moz-calc values are:–moz-column-rule-width, –moz-column-width, letter-spacing, word-spacing, marker-offset, outline-offset, border-spacing, text-shadow and –moz-box-shadow; but work is underway to add this to all properties which accept length values.

Update: You can read more about calc() at hacks.mozilla.org.

Also implemented is a new selector, :-moz-any. With this you can group other simple selectors, removing the need for repetitive code. Consider, for example, a typical web page which has many types of list, and nested lists:

<ul>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</ul>
<ol>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</ol>
<menu>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</menu>

If we wanted to select all of the li children of nested ul elements we would currently have to do this:

ul ul li, ol ul li, menu ul li { property: value; }

But with –moz-any we can group the selectors like so:

:-moz-any(ul,ol,menu) ul li { property: value; }

In my demo page I’ve provided a couple of examples; the first selects all list types which are direct child elements of the body:

body > :-moz-any(ol, ul, menu) {
	float: left;
	width: 33%;
}

And the next selects list items of the lists which are children of those elements:

:-moz-any(ol, ul, menu) ul li {
	font-weight: bold;
	margin-left: 0;
}

The :any selector isn’t in any of the CSS3 modules, but it’s pretty useful and definitely a candidate for inclusion. You can read more about it on the blog of David Baron.

Update: Changed the examples for clarity.

The demo works in Firefox and WebKit.