Only Firefox provides a means to calculate the amount of the video that has been loaded. The progress event object includes total and loaded properties that reflect the total size of the video file, and the amount the browser has retrieved from the server. This is also a reflection of how each browser handles video downloads.

Erm, that’s only sort of true. As zcorpan explained in the comments, the latest version of Firefox implements an old version of the specification.

In the most recent version of the HTML5 spec, the total and loaded properties of the progress event were removed and (mostly) replaced by the video.buffered property.

So while Firefox 3.6.x is still the only browser that provides total and loaded properties in the progress event, the latest revision added a new property to the video element that works similarly — note the emphasis on ‘similarly.’

What’s the difference? Both the total and loaded properties of the progress event express the download’s progress in terms of bytes. The video.buffered property expresses the download’s progress in terms of seconds. They’re similar in that you can determine the status of a download, but using seconds instead of bytes is more relevant for seeking within a timed media file.

By checking video.buffered.end(), we can determine how many seconds of the video are available to the browser and provide the relevant error handling (if a user seeks too far) or interface changes (such as a loading progress bar).

I am still learning how the video.buffered property works, particularly in conjunction other properties and events of the video object. I will post more about this later.

One thing to remember: Firefox has not yet implemented the video.buffered property. It is only available in Safari, Chrome and (sort of) in Opera (still learning the ins-and-outs). (And Internet Explorer doesn’t support the video element at all, though version 9 should when it’s released.)

The progress event is fired as the browser loads more of the media file. It may not be fired reliably, however. Chrome, for example, will not fire the progress event if it has cached the video file.

Only Firefox provides a means to calculate the amount of the video that has been loaded. The progress event object includes total and loaded properties that reflect the total size of the video file, and the amount the browser has retrieved from the server. This is also a reflection of how each browser handles video downloads.

Firefox requests partial content on the initial page load, then pauses downloading until the play event is fired. After the play event is fired — whether when the user clicks the ‘play’ button or the video tag has the autoplay attribute — Firefox resumes downloading the video file.

Safari, Chrome, and Opera conversely, download the entire video on page load — they automatically buffer by default. Opera and Chrome, however, will make the video available for play almost immediately, while Safari takes several seconds to download a larger portion of the file. Firefox will behave similarly if when the autobuffer attribute is present.

Presumably because they auto-buffer video, neither Safari, Chrome, nor Opera offer a means by which to detect either the video’s size, nor how much of the video has loaded.

Some example code for handling the progress event (assuming we’re wrapping this video element in a <div> tag with an id of ‘container’). This will return the percentage of the video loaded in Firefox (and other browsers that don’t auto-buffer), and fail silently in other browsers.

var container = document.getElementById('container');
var video = document.createElement(video);
// only Firefox and Opera support Ogg ... oh yeah Chrome does too.
video.setAttribute('src','movie.ogv');
function progressHandler(e){
      if(e.total && e.loaded){
           // percentage of video loaded
          var proportion = Math.round( e.loaded / e.total );
          return proportion * 100;
      } else {
           // do nothing because we're autobuffering.
      }
}
video.addEventListener('progress',progressHandler,false);
container.appendChild(video);

I tested this example in Firefox, Safari, and later versions of Internet Explorer, but it probably works in Opera and Chrome as well.

When I say “you need to learn JavaScript,” I don’t mean “learn how to copy and paste an example,” or “learn how to generate JavaScript with PHP.” I mean learn it as well as you already know PHP — or better.

Why? Because JavaScript drives rich clients, and all indications are that clients will be getting richer. You won’t be able to get away with just adding small snippets of JS to add tooltips and simple animations. Complex processing and UI management will require real knowledge of how to write JS, and how in [sic] interacts with the client’s APIs — the DOM, local storage, networking, OS features, and more.

And I will add: not jQuery, not MooTools, not Dojo, but real, actual, JavaScript (and DOMScripting). Finkler tells you why and points you to some resources for learning more.

• View a working example
• Download the JavaScript

What do you have to do differently to make this work?

The good news is not much . The major difference is the form and added HTML markup.

<form id="customsearch" action="index.html" method="get">
<div id="cssrchdiv">
	<input type="text" name="p" id="term" value="">
	<input type="hidden" name="vs" id="site" value="YOURDOMAINNAME.COM">
</div>
<p>
<button type="submit">Go</button>
</p>
</form>
<!--/search_form -->
<div id="search_results"></div>

In Christian’s example, he set the form’s action to http://search.yahoo.com/search. It works beautifully if you are serving one page of results. But for our purposes, we are going to reload the current search page, parse the query string, and execute the search. That’s also why we need to add a method to the form — “GET” — so that the form’s values get appended to the URL.

I also added a search_results div so that we can inject the results into a containing div (in case you need to integrate it into an existing site design).

The script is released under a BSD license.

And by “building on,” I mean “straight jackin’ it and adding a few more lines of code.”

TraceMonkey, Resig explains, uses a computing technique known as trace trees (PDF) which adds just-in-time native code compilation to SpiderMonkey, Firefox’s current rendering engine.

What does this mean? As Resig explains:

It means that JavaScript is no longer confined by the previously-challenging resource of processing power. With this improvement it’s leap-frogged any sort of traditional and has gone head-to-head with computationally-powerful languages like C.

In other words, we’ll get JavaScript processing speeds that are Usain Bolt-on-crack fast, opening the door for more powerful JavaScript-powered applications.

Firefox’s announcement comes a few months after the WebKit team’s announcement of SquirrelFish, which will be the JavaScript engine used in Safari 4.

Resig and Brendan Eich also point out that these TraceMonkey improvements (and presumably SquirrelFish’s improvements) in conjunction with HTML 5‘s canvas element will mean we’ll see some slick JavaScript animation and game experiences, such as this one by Zachary Johnson.

The obvious roadblock to widespread adoption of all of this whiz-bangy JavaScript+<canvas> goodness is, of course, Internet Explorer. Internet Explorer 7 does not support the canvas element. Version 8 of the browser will not, although there is a workaround for IE7 available.

Still, without the dominant web browser on board — and conceivably not coming on board for at least a few years — the widespread use of JavaScript animations may not take off for some time.

Want to check see TraceMonkey in action? Download a nightly build of Firefox (codenamed Minefield), and in the about:config panel, set javascript.options.jit.content equal to true.

Also check out Mike Schroepfer’s screencast What can you do when your browser is 7 times faster?

It’s an inventive use of your user’s browser history, though I suspect it could potentially be used — in combination with cookies and logins — to detect which of your users are also regular porn surfers.

With that little bit of fearmongering out of the way, I’ll direct you to two Firefox extensions designed to stop such nosy coding (found in the comments on Niall’s post:

• SafeHistory
• SafeCache

As the number of web-based applications grow, so do the number JavaScript frameworks and toolkits with the goal of making cross-browser development an easier process. But which to choose?

Well, that’s where you come in: what is your preferred JavaScript framework or toolkit? Have you tried more than one? What do you think are the strengths and weaknesses of your choice framework or toolkit as compared to others? Or maybe you hate frameworks and toolkits altogether. Duke it out in the comments.

Some of the combatants in this holy war (for those new to JavaScript frameworks and toolkits) include:

• Dojo Toolkit
• Ext JS
• Fleejix.js
• jQuery
• Mochikit
• Modello
• Mootools
• Prototype
• Qooxdoo
• Rico
• Scriptio
• Yahoo! User Interface Library

I explicitly left two libraries off of the list: Moo.fx and Script.aculo.us because they both build on other frameworks (Mootools and Prototype, respectively).

There’s also some debate about the definition and use of the terms ‘framework,’ and ‘library’ (a working definition: Frameworks tend to control the way an applications is structured and manage them from the outside). I doubt very many folks can or care to parse those semantics, and I’m pretty sure I have rolled some libraries into my definition of framework. I ask your forgiveness in advance.

Related posts

• Must have HTML, CSS and JavaScript books?
• Web trend spotting: Sliding, whiz-bangy JavaScript-driven pages
• Recommended viewing: Maintainable Javascript
• Recommended viewing: “Best Practices in Javascript Library Design”

Elsewhere

• Keep JavaScript Simple