Hello, and welcome to the post for Firefox 4 beta 9. If you’re reading this then you’re interested in what we’ve got coming down the pipe for the latest beta for the wonderful browser known as Firefox 4. We’re starting to reach the end of our development cycle for the next release of Firefox and I thought it might be worth it to give a full overview of everything that we’ve got in store for web developers vs. Firefox 3.6. So if you’ve read previous releases, some of this will look familiar. But this is a new beta and we’ve been busy, so there’s something new in here for everyone.

Performance

One of Firefox 4′s main themes is Performance. As such, we’ve done a huge amount of work to improve browser performance across the board, from startup time, to JavaScript performance, to interactive performance and making the user interface easier and more efficient to drive. That being said, here are some of the things we’ve done to improve performance up to Beta 9.

The JaegerMonkey has landed.

And you might have noticed that it’s really fast. This is the world’s first third-generation JavaScript engine, using Baseline JIT technology similar to engines found in other browsers and kicked up a level with the Tracing engine found in Firefox 3.6. As such, we’re competitive on benchmarks such as Sunspider and V8, but we’re also fast at a whole mess of things that we expect to see in the set of next-generation web applications, hence Kraken.

Hardware Acceleration

Firefox 4 supports full hardware acceleration on Windows 7 and Windows Vista via a combination of D2D, DX9 and DX10. This allows us to accelerate everything from Canvas drawing to video rendering. Windows XP users will also enjoy hardware acceleration for many operations because we’re using our new Layers infrastructure along with DX9. And, of course, OSX users have excellent OpenGL support, so we’ve got that covered as well.

Compartments

Compartments, added in Beta 7, is infrastructure that we’ve added to Firefox to improve performance, give us a better base for security and, over the long term, give us better responsiveness because of its positive effects on garbage collection. (Note that there are some parts of Compartments that still have not landed.) If you want to learn about why Compartments are so important, have a look at Andreas Gal’s great post on the topic. He does a great job of explaining what they are and how they work.

Improved DOM performance and style resolution

We’ve made a huge number of improvements to our overall DOM and style resolution performance as well. Although JavaScript gets much of the focus these days, it turns out that in page load and interactive performance, the DOM and style resolution (usually as part of reflowing a document) often affect page performance more than JavaScript. And as such we’ve seen improvement across the board in this area with Firefox 4. In some tests we’re a solid 2x faster than Firefox 3.6.

JavaScript typed arrays

If you’re doing processing with JavaScript and you want to process low-level data, Firefox now supports native typed arrays in JavaScript. This can make a gigantic difference in how fast items are processed if you’re doing WebGL or image manipulation.

In addition, if you’re getting data from an XHR request, you can get that data as a JavaScript native typed array for fast processing with mozResponseArrayBuffer.

JavaScript animation scheduling APIs

We now support events that let you schedule animations from JavaScript. Doing this means you aren’t wasting CPU and battery by running your animations as fast as possible when the underlying rendering engine isn’t going to draw them anyway. (Gecko now has an internal timer for all drawing and will render at a maximum of 60fps, the edge of human perception. It will also turn this timer down to 1fps for tabs that aren’t in the foreground. Use it.) This is most useful for people building libraries, but you should be aware that there’s a better way to animate in Gecko.

Retained layers

As mentioned above, Firefox now has an internal Layers system for improved drawing performance for many types of web pages. Images, fixed backgrounds, inline video, etc. are now rendered to an internal layer and then composited with other parts of a web page in a way that can take advantage of hardware acceleration. This improves the page load time and interactive performance of many web pages.

Asynchronous plug-in painting

On Windows and Linux we now paint plug-ins asynchronously. In previous releases when we wanted to paint a web page that included a plug-in, we would have to ask the plug-in for the data to paint. If a plug-in was slow or was hung, it would make the browser feel slow. Now we’re able to get that data asynchronously, which means that the overall responsiveness of the browser should be improved.

Vastly improved cache

Firefox 4 has a vastly improved disk cache. This disk cache should result in faster start-up performance and runtime performance. But why mention this here? Our expectation is that site owners should see much higher cache hit rates with Firefox 4 as we dynamically set the cache size based on how much space is free on an end-user’s hard drive.

WebGL

Firefox 4 now has WebGL enabled by default. Based on the original 3-D Canvas work by Vladimir Vukićević, this is being widely implemented in browsers. The WebGL spec is on the short path to a 1.0 release and we’re very excited to see this be used in the wild.

Want a demo? Try the amazing Flight of the Navigator where we combine WebGL with a number of other technologies in Firefox 4 — HTML5 video, the Audio API, all remixed with live data from the web.

JavaScript

The new JaegerMonkey engine in Firefox 4 isn’t just faster, it’s also got some new tricks as well. Our goal is to bring new tools to developers and that includes evolving the JavaScript language. Here are two examples of where we’ve made other improvements:

ECMAScript 5

Firefox 4 Beta 9 contains much of the new version of the JavaScript language. Our goal with Firefox 4 is to have industry-leading support for ECMAScript 5, including the new strict mode. You can track our progress on the ES5 bug.

Web Console

Firefox 4 will include the Web Console. This is a new tool that will let you inspect a web page as it’s running, see network activity, see messages logged with console.log, see warnings for a page’s CSS, and a number of other things.

Note this that is something that we’ll be including with Firefox 4 directly. It’s not an add-on.

(Also Firebug will be ready for the final Firefox 4 release.)

HTML5

Firefox has always had excellent support for HTML5, even as far back as Firefox 3.5. Firefox 4 builds on that history with a bunch of new HTML5-related features.

Forms

We’ve started to implement much of HTML5 forms. We include support for new input types, datalist support, new input attributes like autofocus and placeholder, decoupled forms, form options, validation mechanisms, constraint validation and new CSS selectors to bind them all together. There’s a great post up on the Hacks site covering our HTML5 forms support in Firefox 4. If you want more information, check it out.

Parser

Firefox 4 includes an HTML5-ready parser. This parser brings with it some new capabilities, most notably inline SVG, but also improves performance by running the parsing algorithm on its own processor. It also brings our parser algorithm closer to the standard and lays the foundation for consistent parsing across browsers.

Support for WebM

Firefox 4 includes support for WebM, the new royalty-free format for video on the web. It works on YouTube if you join their HTML5 beta. It also works with embedded YouTube videos if you use their new iframe embedding API. (Join the beta and see an example at the bottom of this post.)

Video Buffer API

We now support the buffered attribute for HTML5 video. This means it’s possible to give users an accurate measure of how much video has been buffered instead of having to guess from the download rate and your current position in the stream.

Video “preload” support

We’ve replaced the “autobuffer” attribute for HTML5 video with the new “preload” attribute. This attribute gives you much better control over how videos are pre-buffered if they are included on a page rather than the old on/off system that was included with Firefox 3.5.

History pushState and replaceState

Firefox 4 now supports the HTML5 pushState and replaceState history modification calls. These allow you to create or modify the browser navigation history. These are extremely useful for applications that might want to generate history entries using the hash after the URL (useful for HTML-based slides, for example.) Other sites have been using these APIs to hide history information so that site-internal navigation aids aren’t revealed as part of HTTP-referrers.

Audio sampling and generation API

Firefox 4 includes the Firefox Audio Data API. This API allows you read, modify and write data from audio and video elements. This is now being widely experimented with and people are building some very beautiful things with it.

DOM

Firefox 4 includes a bunch of new DOM functionality, in addition to the performance improvements I mentioned before.

Added support for .click() to the File upload control

You can now call .click() on a hidden File control in order to bring up the platform file upload widget. This means you don’t have to expose the (ugly) file upload control; instead you can build your own. If you combine this with the new File APIs and progress events and you’ve got a recipe for a very nice file upload experience.

Support for .slice in the File API

We now support the Blob API and the .slice APIs that come with it. This is useful for people who want to want to process small parts of an otherwise large File object from JavaScript. You no longer have to load the entire file into memory.

It’s also useful for people who want to reliably upload large files. With some server and JS code you can now split a large file into small sections and upload those chunks, including re-retrying failed sections, or even uploading several sections in parallel.

Support for File API URLs

We now support the .url attribute for the File API. This lets you take objects that you’ve gotten through the File API and use them for images, video, HTML or other URL-powered objects.

Touch and multi-touch events

Firefox 4 supports both touch and multi-touch events, exposed to the DOM. Support for this functionality is available on Windows 7 systems.

Detect click-to-touch

You can now tell if a mouse or finger generated an event with the mozInputSource property. This is useful with the touch and multi-touch events and makes it possible to build apps that treat touch and mouse input differently.

IndexedDB

Firefox 4 will include a super-early version of IndexedDB. This emerging standard for local storage is still undergoing change and will be private-prefixed until it’s stable. We have some early API docs on IndexedDB, but the spec and implementation we have in Firefox 4 have both changed since the docs were last updated. As we get closer to release time we’ll be updating the docs and talk more about the implementation. Meanwhile, you can read the IndexedDB primer for an overview of using the IndexedDB API.

FormData

Firefox 4 includes support for the new FormData object, which makes it easier to interact with HTML forms. It also enables some new capabilities, like making it easy to upload a file as part of a form accessed via the File API.

SVG Animation and SMIL

In Firefox 4 you can now animate SVG with SMIL.

SVG as Images and CSS backgrounds

You can now use SVG as the source of an <img> tag. You can even animate them with SMIL. And you can also use SVGs as backgrounds in CSS.

Get a Canvas as a File object

Many people wanted a Canvas accessible as a file object for uploads and other purposes. You can now use the mozGetAsFile() method on a canvas and it will return an image file.

Resizable text areas

If you’ve been using a beta, you’ve noticed that text areas are now resizable by default. You can disable that with the new resize CSS property.

CSS

Firefox 4 includes a huge pile of new CSS properties and promotions from the private CSS namespace into the final namespace due to the maturation of some of the standards in this space.

CSS Transitions

Firefox 4 will include support for CSS Transitions. Since the spec is still early, these are still -moz prefixed extensions.

calc()

We now support an early version of calc private-namespaced as -moz-calc. This will let you use simple expressions anywhere you would normally want to use a length. This can make the CSS layout of pages much simpler. (No more divs for spacing!)

-moz-any()

We now support a new extremely useful CSS extension: -moz-any() selector grouping. This will be very useful in HTML5 contexts. Please read the post for more information.

-moz-element()

The -moz-element is an extension to the background-image property that lets you use any element as the background for another element. This is hugely useful & powerful and we hope that other browsers will adopt it as well.

-moz-placeholder()

The :-moz-placeholder allows you to change the attributes of background text that’s a placeholder in an HTML5 form. This allows you to change the color or other attribute of the text. This can be very useful if you’ve changed the style of the actual text box and you want the background text to match.

border-radius

The border-radius attribute is now supported, replacing the old -moz-border-radius attribute.

box-shadow

box-shadow has replaced -moz-box-shadow.

-moz-font-feature-settings

Firefox 4 will include support for exposing much more of the capabilities of TrueType fonts with the -moz-font-feature-settings property. It’s possible to take advantage of all kinds of font capabilities — kerning, ligatures, alternates, real small caps, and stylistic sets, to name just a few.

Consistent CSS units

We’ve changed our handling of pixel sizes to match Internet Explorer, Safari and Chrome so that 1 inch always equals 96 pixels. See Robert’s post for more information on these changes.

Support for a physical CSS unit

We’ve introduced a new CSS unit, mozmm for the rare instance where you actually want a physical size to be used. Once again, see Robert’s post for more information on this new unit.

device-pixel-ratio

Firefox now supports the -moz-device-pixel-ratio media query that gives you the number of device pixels per CSS pixel.

resize

As mentioned above, we now have a resize CSS property that lets you disable resizable input text areas.

-moz-tab-size

We now support the -moz-tab-size property that lets you specify the width in space characters of how to render a tab character (U+0009) when rendering text.

-moz-focusring

The new CSS pseudo-selector, -moz-focusring lets you specify the appearance of an element when it’s focused and it would have a focus ring drawn around it. Different operating systems have different conventions for when to draw a focus ring or not and this lets you control the look of form controls while keeping to platform conventions.

-moz-image-rect

The new -moz-image-rect lets you use a sub-rectangle of an image as part of a background or background-image.

Security

Last but not least, Firefox 4 supports a huge number of new security tools, useful for both users and web developers alike. Here’s a quick overview of the new technologies we’re delivering:

Content Security Policy

Content Security Policy (CSP) is a set of tools that web developers can use to help prevent a couple different classes of attacks. In particular, it offers tools to mitigate cross-site scripting attacks, click-jacking and packet sniffing attacks.

Another important piece of CSP is that when one of the rules is violated, Firefox can send back information about that violation to the web site, making it a useful canary to improve security for other browsers too.

X-Frame-Options

Firefox 4 now supports the X-Frame-Options header, one defense against clickjacking. This response header is supported by other browsers as well. (This was also delivered as part of a Firefox 3.6 update, but is worth calling out since it’s new since the original 3.6 release.)

HSTS (ForceTLS)

Firefox 4 supports the obtusely-named HTTP Strict Transport Security (HSTS) headers. You can use these headers to tell the browser that it should never, ever contact a site over unencrypted HTTP.

Firefox users can also use the STS UI add-on to add and remove sites from the HSTS list, even sites that don’t natively support HSTS.

CORS Improvements

We’ve fixed some bugs in our CORS implementation.

:visited changes

Firefox 4 includes the changes required to help improve your privacy online by closing a decade-old hole in CSS rules that let any website query your browsing history. These changes have also been picked up by WebKit-based browsers and we’ve heard rumors that IE 9 might pick up this important change as well.

That’s a lot of stuff

Yes, it really is! We hope that you like it.

HTML5 comes with a set of really awesome APIs. If you combine these APIs with the <canvas> element, you could create a super/modern/awesome Image Uploader. This article shows you how.

All these tips work well in Firefox 4. I also describe some alternative ways to make sure it works on Webkit-based browsers. Most of these APIs don’t work in IE, but it’s quite easy to use a normal form as a fallback.

Please let us know if you use one of these technologies in your project!

Retrieve the images

Drag and drop

To upload files, you’ll need an <input type=”file”> element. But you should also allow the user to drag and drop images from the desktop directly to your web page.

I’ve written a detailed article about implementing drag-and-drop support for your web pages.

Also, take a look at the Mozilla tutorial on drag-and-drop.

Multiple input

Allow the user the select several files to upload at the same time from the File Picker:

<input type="file" multiple>

Again, here is an article I’ve written about multiple file selection.

Pre-process the files

Use the File API

(See the File API documentation for details.)

From drag-and-drop or from the <input> element, you have a list a files ready to be used:

// from an input element
var filesToUpload = input.files;
// from drag-and-drop
function onDrop(e) {
  filesToUpload = e.dataTransfer.files;
}

Make sure these files are actually images:

if (!file.type.match(/image.*/)) {
  // this file is not an image.
};

Show a thumbnail/preview

There are two options here. You can either use a FileReader (from the File API) or use the new createObjectURL() method.

createObjectURL()

var img = document.createElement("img");
img.src = window.URL.createObjectURL(file);

FileReader

var img = document.createElement("img");
var reader = new FileReader();  
reader.onload = function(e) {img.src = e.target.result}
reader.readAsDataURL(file);

Use a canvas

Once you have the image preview in an <img> element, you can draw this image in a <canvas> element to pre-process the file.

var ctx = canvas.getContext("2d");
ctx.drawImage(img, 0, 0);

Resize the image

People are used to uploading images straight from their camera. This gives high resolution and extremely heavy (several megabyte) files. Depending on the usage, you may want to resize such images. A super easy trick is to simply have a small canvas (800×600 for example) and to draw the image tag into this canvas. Of course, you’ll have to update the canvas dimensions to keep the ratio of the image.

var MAX_WIDTH = 800;
var MAX_HEIGHT = 600;
var width = img.width;
var height = img.height;
 
if (width > height) {
  if (width > MAX_WIDTH) {
    height *= MAX_WIDTH / width;
    width = MAX_WIDTH;
  }
} else {
  if (height > MAX_HEIGHT) {
    width *= MAX_HEIGHT / height;
    height = MAX_HEIGHT;
  }
}
canvas.width = width;
canvas.height = height;
var ctx = canvas.getContext("2d");
ctx.drawImage(img, 0, 0, width, height);

Edit the image

Now, you have your image in a canvas. Basically, the possibilities are infinite. Let’s say you want to apply a sepia filter:

var imgData = ctx.createImageData(width, height);
var data = imgData.data;
var pixels = ctx.getImageData(0, 0, width, height);
for (var i = 0, ii = pixels.data.length; i < ii; i += 4) {
    var r = pixels.data[i + 0];
    var g =pixels.data[i + 1];
    var b = this.pixels.data[i + 2];
    data[i + 0] = (r * .393) + (g *.769) + (b * .189);
    data[i + 1] = (r * .349) + (g *.686) + (b * .168)
    data[i + 2] = (r * .272) + (g *.534) + (b * .131)
    data[i + 3] = 255;
}
ctx.putImageData(imgData, 0, 0);

Upload with XMLHttpRequest

Now that you have loaded the images on the client, eventually you want to send them to the server.

How to send a canvas

Again, you have two options. You can convert the canvas to a data URL or (in Firefox) create a file from the canvas.

canvas.toDataURL()

var dataurl = canvas.toDataURL("image/png");

Create a file from the canvas

var file = canvas.mozGetAsFile("foo.png");

Atomic upload

Allow the user to upload just one file or all the files at the same time.

Show progress of the upload

Use the upload events to create a progress bar:

xhr.upload.addEventListener("progress", function(e) {
  if (e.lengthComputable) {
    var percentage = Math.round((e.loaded * 100) / e.total);
    // do something
}, false);

Use FormData

You probably don’t want to just upload the file (which could be easily done via: xhr.send(file)) but add side information (like a key and a name).

In that case, you’ll need to create a multipart/form-data request via a FormData object. (See Firefox 4: easier JS form handling with FormData.)

var fd = new FormData();
fd.append("name", "paul");
fd.append("image", canvas.mozGetAsFile("foo.png"));
fd.append("key", "××××××××××××");
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://your.api.com/upload.json");
xhr.send(fd);

Open your API

Maybe you want to allow other websites to use your service.

Allow cross-domain requests

By default, your API is only reachable from a request created from your own domain. If you want to allow people use your API, allow Cross-XHR in your HTTP header:

Access-Control-Allow-Origin: *

You can also allow just a pre-defined list of domains.

Read about Cross-Origin Resource Sharing.

postMessage

(Thanks to Daniel Goodwin for this tip.)

Also, listen to messages sent from postMessage. You could allow people to use your API through postMessage:

document.addEventListener("message", function(e){
    // retrieve parameters from e.data
    var key = e.data.key;
    var name = e.data.name;
    var dataurl = e.data.dataurl;
    // Upload
}
// Once the upload is done, you can send a postMessage to the original window, with URL

That’s all. If you have any other tips to share, feel free to drop a comment.

Enjoy ;)

Editor’s note: This article is posted by Chris Heilmann but authored by Jeff Walden – credit where credit is due.

Developers in the Mozilla community have made major improvements to the JavaScript engine in Firefox 4. We have devoted much effort to improving performance, but we’ve also worked on new features. We have particularly focused on ECMAScript 5, the latest update to the standard underlying JavaScript.

Strict mode is arguably the most interesting new feature in ECMAScript 5. It’s a way to opt in to a restricted variant of JavaScript. Strict mode isn’t just a subset: it intentionally has different semantics from normal code. Browsers not supporting strict mode will run strict mode code with different behavior from browsers that do, so don’t rely on strict mode without feature-testing for support for the relevant aspects of strict mode.

Strict mode code and non-strict mode code can coexist, so scripts can opt into strict mode incrementally. Strict mode blazes a path to future ECMAScript editions where new code with a particular <script type="..."> will likely automatically be executed in strict mode.

What does strict mode do? First, it eliminates some JavaScript pitfalls that didn’t cause errors by changing them to produce errors. Second, it fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that’s not strict mode. Firefox 4 generally hasn’t optimized strict mode yet, but subsequent versions will. Third, it prohibits some syntax likely to be defined in future versions of ECMAScript.

Invoking strict mode

Strict mode applies to entire scripts or to individual functions. It doesn’t apply to block statements enclosed in {} braces; attempting to apply it to such contexts does nothing. eval code, event handler attributes, strings passed to setTimeout, and the like are entire scripts, and invoking strict mode in them works as expected.

Strict mode for scripts

To invoke strict mode for an entire script, put the exact statement "use strict"; (or 'use strict';) before any other statements.

// Whole-script strict mode syntax
"use strict";
var v = "Hi!  I'm a strict mode script!";

This syntax has a trap that has already bitten a major site: it isn’t possible to blindly concatenate non-conflicting scripts. Consider concatenating a strict mode script with a non-strict mode script: the entire concatenation looks strict! The inverse is also true: non-strict plus strict looks non-strict. Concatenation of strict mode scripts with each other is fine, and concatenation of non-strict mode scripts is fine. Only crossing the streams by concatenating strict and non-strict scripts is problematic.

Strict mode for functions

Likewise, to invoke strict mode for a function, put the exact statement "use strict"; (or 'use strict';) in the function’s body before any other statements.

function strict()
{
  // Function-level strict mode syntax
  'use strict';
  function nested() { return "And so am I!"; }
  return "Hi!  I'm a strict mode function!  " + nested();
}
function notStrict() { return "I'm not strict."; }

Changes in strict mode

Strict mode changes both syntax and runtime behavior. Changes generally fall into these categories:

• Converting mistakes into errors (as syntax errors or at runtime)
• Simplifying how the particular variable for a given use of a name is computed
• Simplifying eval and arguments
• Making it easier to write “secure” JavaScript
• Anticipating future ECMAScript evolution

Converting mistakes into errors

Strict mode changes some previously-accepted mistakes into errors. JavaScript was designed to be easy for novice developers, and sometimes it gives operations which should be errors non-error semantics. Sometimes this fixes the immediate problem, but sometimes this creates worse problems in the future. Strict mode treats these mistakes as errors so that they’re discovered and promptly fixed.

First, strict mode makes it impossible to accidentally create global variables. In normal JavaScript, mistyping a variable in an assignment creates a new property on the global object and continues to “work” (although future failure is possible: likely, in modern JavaScript). Assignments which would accidentally create global variables instead throw errors in strict mode:

"use strict";
mistypedVaraible = 17; // throws a ReferenceError

Second, strict mode makes assignments which would otherwise silently fail throw an exception. For example, NaN is a non-writable global variable. In normal code assigning to NaN does nothing; the developer receives no failure feedback. In strict mode assigning to NaN throws an exception. Any assignment that silently fails in normal code will throw errors in strict mode:

"use strict";
NaN = 42; // throws a TypeError
var obj = { get x() { return 17; } };
obj.x = 5; // throws a TypeError
var fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // throws a TypeError

Third, if you attempt to delete undeletable properties, strict mode throws errors (where before the attempt would simply have no effect):

"use strict";
delete Object.prototype; // throws a TypeError

Fourth, strict mode requires that all properties named in an object literal be unique. Normal code may duplicate property names, with the last one determining the property’s value. But since only the last one does anything, the duplication is simply a vector for bugs, if the code is modified to change the property value other than by changing the last instance. Duplicate property names are a syntax error in strict mode:

"use strict";
var o = { p: 1, p: 2 }; // !!! syntax error

Fifth, strict mode requires that function argument names be unique. In normal code the last duplicated argument hides previous identically-named arguments. Those previous arguments remain available through arguments[i], so they’re not completely inaccessible. Still, this hiding makes little sense and is probably undesirable (it might hide a typo, for example), so in strict mode duplicate argument names are a syntax error:

function sum(a, a, c) // !!! syntax error
{
  "use strict";
  return a + b + c; // wrong if this code ran
}

Sixth, strict mode forbids octal syntax. Octal syntax isn’t part of ECMAScript, but it’s supported in all browsers by prefixing the octal number with a zero: 0644 === 420 and "\\045" === "%". Novice developers sometimes believe a leading zero prefix has no semantic meaning, so they use it as an alignment device — but this changes the number’s meaning! Octal syntax is rarely useful and can be mistakenly used, so strict mode makes octal a syntax error:

"use strict";
var sum = 015 + // !!! syntax error
          197 +
          142;

Simplifying variable uses

Strict mode simplifies how variable uses map to particular variable definitions in the code. Many compiler optimizations rely on the ability to say that this variable is stored in this location: this is critical to fully optimizing JavaScript code. JavaScript sometimes makes this basic mapping of name to variable definition in the code impossible to perform except at runtime. Strict mode removes most cases where this happens, so the compiler can better optimize strict mode code.

First, strict mode prohibits with. The problem with with is that any name in it might map either to a property of the object passed to it, or to a variable in surrounding code, at runtime: it’s impossible to know which beforehand. Strict mode makes with a syntax error, so there’s no chance for a name in a with to refer to an unknown location at runtime:

"use strict";
var x = 17;
with (obj) // !!! syntax error
{
  // If this weren't strict mode, would this be var x, or
  // would it instead be obj.x?  It's impossible in general
  // to say without running the code, so the name can't be
  // optimized.
  x;
}

The simple alternative of assigning the object to a variable, then accessing the corresponding property on that variable, stands ready to replace with.

Second, eval of strict mode code does not introduce new variables into the surrounding code. In normal code eval("var x;") introduces a variable x into the surrounding function or the global scope. This means that, in general, in a function containing a call to eval, every name not referring to an argument or local variable must be mapped to a particular definition at runtime (because that eval might have introduced a new variable that would hide the outer variable). In strict mode eval creates variables only for the code being evaluated, so eval can’t affect whether a name refers to an outer variable or some local variable:

var x = 17;
var evalX = eval("'use strict'; var x = 42; x");
assert(x === 17);
assert(evalX === 42);

Relatedly, if the function eval is invoked by an expression of the form eval(...) in strict mode code, the code will be evaluated as strict mode code. The code may explicitly invoke strict mode, but it’s unnecessary to do so.

function strict1(str)
{
  "use strict";
  return eval(str); // str will be treated as strict mode code
}
function strict2(f, str)
{
  "use strict";
  return f(str); // not eval(...): str is strict iff it invokes strict mode
}
function nonstrict(str)
{
  return eval(str); // str is strict iff it invokes strict mode
}
strict1("'Strict mode code!'");
strict1("'use strict'; 'Strict mode code!'");
strict2(eval, "'Non-strict code.'");
strict2(eval, "'use strict'; 'Strict mode code!'");
nonstrict("'Non-strict code.'");
nonstrict("'use strict'; 'Strict mode code!'");

Third, strict mode forbids deleting plain names. Thus names in strict mode eval code behave identically to names in strict mode code not being evaluated as the result of eval. Using delete name in strict mode is a syntax error:

"use strict";
eval("var x; delete x;"); // !!! syntax error

Making eval and arguments simpler

Strict mode makes arguments and eval less bizarrely magical. Both involve a considerable amount of magical behavior in normal code: eval to add or remove bindings and to change binding values, and arguments by its indexed properties aliasing named arguments. Strict mode makes great strides toward treating eval and arguments as keywords, although full fixes will not come until a future edition of ECMAScript.

First, the names eval and arguments can’t be bound or assigned in language syntax. All these attempts to do so are syntax errors:

"use strict";
eval = 17;
arguments++;
++eval;
var obj = { set p(arguments) { } };
var eval;
try { } catch (arguments) { }
function x(eval) { }
function arguments() { }
var y = function eval() { };
var f = new Function("arguments", "'use strict'; return 17;");

Second, strict mode code doesn’t alias properties of arguments objects created within it. In normal code within a function whose first argument is arg, setting arg also sets arguments[0], and vice versa (unless no arguments were provided or arguments[0] is deleted). For strict mode functions, arguments objects store the original arguments when the function was invoked. The value of arguments[i] does not track the value of the corresponding named argument, nor does a named argument track the value in the corresponding arguments[i].

function f(a)
{
  "use strict";
  a = 42;
  return [a, arguments[0]];
}
var pair = f(17);
assert(pair[0] === 42);
assert(pair[1] === 17);

Third, arguments.callee is no longer supported. In normal code arguments.callee refers to the enclosing function. This use case is weak: simply name the enclosing function! Moreover, arguments.callee substantially hinders optimizations like inlining functions, because it must be made possible to provide a reference to the un-inlined function if arguments.callee is accessed. For strict mode functions, arguments.callee is a non-deletable property which throws an error when set or retrieved:

"use strict";
var f = function() { return arguments.callee; };
f(); // throws a TypeError

“Securing” JavaScript

Strict mode makes it easier to write “secure” JavaScript. Some websites now provide ways for users to write JavaScript which will be run by the website on behalf of other users. JavaScript in browsers can access the user’s private information, so such JavaScript must be partially transformed before it is run, to censor access to forbidden functionality. JavaScript’s flexibility makes it effectively impossible to do this without many runtime checks. Certain language functions are so pervasive that performing runtime checks has considerable performance cost. A few strict mode tweaks, plus requiring that user-submitted JavaScript be strict mode code and that it be invoked in a certain manner, substantially reduce the need for those runtime checks.

First, the value passed as this to a function in strict mode isn’t boxed into an object. For a normal function, this is always an object: the provided object if called with an object-valued this; the value, boxed, if called with a Boolean, string, or number this; or the global object if called with an undefined or null this. (Use call, apply, or bind to specify a particular this.) Automatic boxing is a performance cost, but exposing the global object in browsers is a security hazard, because the global object provides access to functionality “secure” JavaScript environments must invariably. Thus for a strict mode function, the specified this is used unchanged:

"use strict";
function fun() { return this; }
assert(fun() === undefined);
assert(fun.call(2) === 2);
assert(fun.apply(null) === null);
assert(fun.call(undefined) === undefined);
assert(fun.bind(true)() === true);

(Tangentially, built-in methods also now won’t box this if it is null or undefined. [This change is independent of strict mode but is motivated by the same concern about exposing the global object.] Historically, passing null or undefined to a built-in method like Array.prototype.sort() would act as if the global object had been specified. Now passing either value as this to most built-in methods throws a TypeError. Booleans, numbers, and strings are still boxed by these methods: it’s only when these methods would otherwise act on the global object that they’ve been changed.)

Second, in strict mode it’s no longer possible to “walk” the JavaScript stack via commonly-implemented extensions to ECMAScript. In normal code with these extensions, when a function fun is in the middle of being called, fun.caller is the function that most recently called fun, and fun.arguments is the arguments for that invocation of fun. Both extensions are problematic for “secure” JavaScript, because they allow “secured” code to access “privileged” functions and their (potentially unsecured) arguments. If fun is in strict mode, both fun.caller and fun.arguments are non-deletable properties which throw an error when set or retrieved:

function restricted()
{
  "use strict";
  restricted.caller;    // throws a TypeError
  restricted.arguments; // throws a TypeError
}
function privilegedInvoker()
{
  return restricted();
}
privilegedInvoker();

Third, arguments for strict mode functions no longer provide access to the corresponding function call’s variables. In some old ECMAScript implementations arguments.caller was an object whose properties aliased variables in that function. This is a security hazard because it breaks the ability to hide privileged values via function abstraction; it also precludes most optimizations. For these reasons no recent browsers implement it. Yet because of its historical functionality, arguments.caller for a strict mode function is also a non-deletable property which throws an error when set or retrieved:

"use strict";
function fun(a, b)
{
  "use strict";
  var v = 12;
  return arguments.caller; // throws a TypeError
}
fun(1, 2); // doesn't expose v (or a or b)

Paving the way for future ECMAScript versions

Future ECMAScript versions will likely introduce new syntax, and strict mode in ECMAScript 5 applies some restrictions to ease the transition. It will be easier to make some changes if the foundations of those changes are prohibited in strict mode.

First, in strict mode a short list of identifiers become reserved keywords. These words are implements, interface, let, package, private, protected, public, static, and yield. In strict mode, then, you can’t name or use variables or arguments with these names. A Mozilla-specific caveat: if your code is JavaScript 1.7 or greater (you’re chrome code, or you’ve used the right <script type="">) and is strict mode code, let and yield have the functionality they’ve had since those keywords were first introduced. But strict mode code on the web, loaded with <script src=""> or <script>...</script>, won’t be able to use let/yield as identifiers.

Second, strict mode prohibits function statements not at the top level of a script or function. In normal code in browsers, function statements are permitted “everywhere”. This is not part of ES5! It’s an extension with incompatible semantics in different browsers. Future ECMAScript editions hope to specify new semantics for function statements not at the top level of a script or function. Prohibiting such function statements in strict mode “clears the deck” for specification in a future ECMAScript release:

"use strict";
if (true)
{
  function f() { } // !!! syntax error
  f();
}
for (var i = 0; i < 5; i++)
{
  function f2() { } // !!! syntax error
  f2();
}
function baz() // kosher
{
  function eit() { } // also kosher
}

This prohibition isn’t strict mode proper, because such function statements are an extension. But it is the recommendation of the ECMAScript committee, and browsers will implement it.

Strict mode in browsers

Firefox 4 is the first browser to fully implement strict mode. The Nitro engine found in many WebKit browsers isn’t far behind with nearly-complete strict mode support. Chrome has also started to implement strict mode. Internet Explorer and Opera haven’t started to implement strict mode; feel free to send those browser makers feedback requesting strict mode support.

Browsers don’t reliably implement strict mode, so don’t blindly depend on it. Strict mode changes semantics. Relying on those changes will cause mistakes and errors in browsers which don’t implement strict mode. Exercise caution in using strict mode, and back up reliance on strict mode with feature tests that check whether relevant features of strict mode are implemented.

To test out strict mode, download a Firefox nightly and start playing. Also consider its restrictions when writing new code and when updating existing code. (To be absolutely safe, however, it’s probably best to wait to use it in production until it’s shipped in browsers.)

Leggi la traduzione in italiano

HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

The first person to feature is Bruce Lawson of Opera, co-author of Introducing HTML5 and one of the curators of HTML5 Doctor.

Bruce works from home somewhere in the darker and unknown regions of England, and if you haven’t had the chance to see him speak, make sure to catch one of his talks. Also, despite his disturbing fetish for cheesy cam effects, he really knows his stuff and is a very funny man to boot.

You can find Bruce on Twitter as @brucel.

The video interview

Watch the video on YouTube or Download it from Archive.org as WebM (45MB), OGG (70 MB) or MP4 (70 MB)

Ten questions about HTML5 for Bruce Lawson

1) What, in your view, is HTML5 and what does it mean for web development as a whole?

It’s the language for web applications: it makes writing apps more robust, more interoperable and expands the capabilities of browsers so the web can come closer to native apps.

2) How did you get involved in the HTML5 world? What is your background and even more importantly, what drives you?

My background is in accessibility and writing markup. So getting involved in the development of the new language for the Web was too exciting to pass over, and because Opera (my employer) was so closely associated with the genesis of HTML5, it was easy to persuade my boss to let me have the time!

3) What do you consider the most exciting of the new technologies?

HTML5, of course — and also DAP (“Device APIs and Policy Working Group”). This thrillingly-named set of specifications is further extending the capabilities of the Web by specifying APIs that allow access to device features like camera, contact books and calendar — much like Geolocation gives browsers access to the device’s GPS capabilities. Like HTML5, the DAP are adapting existing proprietary APIs that have been road-tested, and other manufacturers have committed to supporting the specifications.

4) You’ve co-authored “Introducing HTML5″ — what was the most frustrating part about writing an HTML5 book? Isn’t HTML5 still a bit of a moving target?

Apart from the freakishly anachronistic processes behind dead-tree publishing (everything to be submitted in Microsoft Word!) the hardest part was the fact that the spec kept moving from under us. The chapter on video had just been proofread and indexed when the webM format was announced and we had to rewrite. But we were pretty sure that most of the stuff that was ready to use was pretty stable — and in a short Introductory book, we weren’t trying to cover the more esoteric areas, anyway.

5) You’ve been advocating using the term “NEWT” instead of talking about HTML5, what does that mean and why not HTML5 as an umbrella term?

Clients and journalists will use “HTML5″ to mean CSS 3/video-that-runs-on-iThings/Geo-enabled applications. It’s the new “Web 2.0″. But we practitioners need to get our nomenclature straight. There are no HTML5 image transitions, just as there are no CSS semantics — and to say there are shows that you didn’t get the 2001 memo about separating style and content.

If we need an over-all term to encompass DAP, CSS 3, HTML5, Geolocation, SVG, WebGL, then let’s call it the Open Web Stack. But, because people seem to like easy-to-pronounce acronyms and cute logos, I proposed NEWT as a tongue-in-cheek way to highlight the jargon abuse I see happening.

6) What is in your opinion the biggest obstacle to mainstream HTML5 adoption?

Developer ignorance: “I can’t use it because it’s not finished” and “I can’t use it because I still have to support IE6″ are the main stumbling blocks. “It’s not finished” annoys me the most. Perhaps we should stop using the English language because it’s “not finished yet” and move to French, as that was apparently finished in 1799.

Then there’s the IE6 fallacy. The HTML5 Shim allows you to style HTML5 elements in IE6, as long as you have JavaScript. If a visitor is surfing the Web with IE6 and JS turned off, their experience of the whole Web will be pretty dreadful and your site won’t be any worse.

And, of course, it’s not The Law that you must use HTML5; it’s really for Web applications. HTML4 and XHTML 1 will continue to work fine for documents.

7) There are a lot of fixes right now available to make HTML5 degrade gracefully on older browsers and IE6. If you look, for example, at the HTML5 boilerplate, this seems a lot of work and extra code and files. Is this worth it? What is your stance on so called “polyfills”?

All you really need is Remy’s HTML5 Shim so you can style your new HTML5 elements. Depending on your project you choose individual polyfills. is it a lot of work? Perhaps — but is linking to a pre-written polyfill that fakes WebSockets in old browsers harder work than writing that functionality from scratch and making it work in IE6 to 8?

Polyfills come with built-in obsolescence. They’re only needed for old browsers, and by definition, that’s a dwindling number of installs. Newer browsers don’t even know of their existence. It ain’t pretty, but feature detection and polyfilling are better than browser sniffing or locking out users.

8) Is there something in the HTML5 recommendations and specs that ails you? Are they taking a direction you don’t agree with?

I wish that accessibility aspects of canvas had been specified long ago, so that they were in browsers now. People are already abusing canvas to make User Interfaces, and it’s going to be the biggest problem, I think. I also think it’s silly that you can’t use CITE around the name of a person, which is one of the few instances of breaking backwards compatibility with HTML4.

9) If I wanted to learn about HTML5, where would you say is the best place to start?

There’s a wonderful book that introduces HTML5. The title escapes me for a moment… Mark Pilgrim has an online book, too, which is pretty good. I co-curate a site called HTML5 Doctor which has a lot of beginner’s articles in tasty morsels. There are, unfortunately, so-called schools sites with out-of-date information and even published books based on archaic versions of the spec.

10) HTML5 takes a much more lenient approach to markup than HTML4.01 strict or XHTML. You can for example mix upper and lowercase tags and omit the quotes around attributes. Isn’t that a step back in terms of code quality?

Nope. It should be easy for people to move their sites from XHTML 1 or HTML4, and browsers never cared about syntax (when served text/html), so why impose an arbitrary rule forbidding lower case, or upper case, or requiring trailing slashes? Authors should pick a style that works for them and stick to it. Sites like HTML Lint offer the ability to opt-in to “lifestyle” syntactical choices like quoting attributes, lower case, etc. and I expect authoring tools to do the same.

The real test of quality is the DOM that the browser constructs from the code, and when browsers have HTML5 parsers, they’ll construct identical DOMs even from invalid code, which is a fantastic win for the interoperable Web.

Bonus: What’s next? What do you consider the next big issue we need to fix to make the web a better place and easier to build for it?

We need a CSS layout mechanism that can be understood by mere mortals, some real accessibility for canvas and webGL, and more pictures of nude Open Standards evangelists.

Do you know anyone I should interview for “People of HTML5″? Tell me on Twitter: @codepo8

As I mentioned in my post about ways you can help improve MDN in 2011, we are holding a virtual sprint to write documentation on MDN next week, January 28 to 29.

“Virtual” means that there will not be an in-person meeting, but rather people will participate from wherever they are, discussing what we’re doing via IRC. Please join us for any portion of the scheduled 34 hours of sprint time. If you’re not sure what to work on, just ask (either before or during the sprint), and we can help you find something appropriate to your background and interests.

Check out the doc sprint planning page for more details. Add your name under “Who” if you think you might help out.

By the way, if you’re not familiar with IRC, it’s a real-time text chat protocol that Mozilla uses a lot. If you don’t have a favorite IRC client program, you can use the ChatZilla add-on for Firefox, or the MiBBit website. Specify the server as irc.mozilla.org on port 6697 using SSL, pick a nickname, and connect to the #devmo channel. (If you’re having trouble with all that, you can use the mozilla.dev.mdc Google group to ask for help. Sorry about the spam in there, but I will see and respond if you post.)

Oh, and did I mention the t-shirts?

Make a non-trivial contribution during the sprint, and send me your size and mailing address, and I will make sure you get a t-shirt featuring the MDN robot-dino. (Your personal info will be handled according to the Mozilla privacy policy. I promise not to show up at your door demanding more documentation.)

This is a guest post from Ben Turner, one of the developers of IndexedDB for Firefox.

Mozilla is pleased to announce support for IndexedDB in the upcoming Firefox 4 Beta 9 and recent trunk nightlies. IndexedDB allows web apps to store large amounts of data on your local system (with your explicit permission, of course) for fast offline retrieval at a later time. We’re hoping that webmail, TV listings, and online purchase history will one day be as convenient to access offline as they are online.

Web developers who are interested in using this new feature are encouraged to read the IndexedDB primer on Mozilla Developer Network. The primer attempts to strip away some of the complexity in the specification, to discuss the most important concepts and provide simple examples. The truly hardcore are of course welcome to read the entire specification.

Keep in mind that IndexedDB is brand new and is not uniformly supported by all browsers, and please file bugs for any behavior that seems to contradict the specification!

More than 30 contributors from at least a dozen countries, touching approximately 300 documentation pages.

Those are the results from the documentation sprint that started Friday, January 28 at 14:00 UTC. While the sprint was scheduled to end at midnight UTC on Saturday, some participants were still making updates on Sunday.

This sprint provided a couple of instances of cooperation with other organizations that I believe bodes well for MDN’s future as a resource, not just for Mozilla technologies, but for open web technologies in general.

Paul Irish, developer relations dude for Google Chrome, and one of the folks behind Modernizr and HTML5 Boilerplate, helped muster participants, and then during the sprint, added browser compatibility tables for a number of CSS and DOM pages.

Colin Clark and Anastasia Cheetham from the Inclusive Design Research Centre began work on updating and migrating information on accessibility and ARIA from the CodeTalks wiki to MDN. Colin first approached me about the possibility of doing this during the Mozilla Drumbeat Festival, back in November. During the sprint, Colin created An overview of accessible web applications and widgets, and Anastasia created Keyboard-navigable JavaScript widgets.

Below is a summary of the work that was accomplished. Given the massive amount of work that was done, I might have omitted something; if so, please let me know and I’ll correct this post. I am deeply grateful to everyone who contributed, and especially to those who spent large chunks of their weekend free time on the sprint.

• Jeremie Patonnier created a categorical classification of SVG elements, created pages for 38(!) of the 80 SVG elements and cleaned up some existing elements, thereby covering all the basic elements. He also populated the index page for SVG attributes, and interlinked the element and attribute pages. As a result, the SVG reference now has a structure, and the beginnings of useful docs.
• Manuel Strehl made significant updates to many sections of the SVG Tutorial, complementing Jeremie’s work on the SVG reference.
• Tom Schuster created a mapping of HTML Attributes to the elements they belong to, and several other people added descriptions. Tom also updated Array.toString and Object.toString, and cleaned up reference pages for basic JavaScript types, including adding version information and fixing syntax.
• Marc-Aurèle Darche made improvements to the XUL tutorial Element Positioning article, and XUL attribute dlgtype.
• wellington7 cleaned up Creating a skin for Firefox/Getting started.
• Masahiko Imanaka translated some pages about CSS column properties into Japanese.
• Jonathan Wilsson created pages for CSS page-related pseudo-classes and pseudo-elements, re-wrote the page for pseudo-classes, added examples, syntax highlighting, and tags to a whole bunch of HTML element pages, created the HTMLParagraphElement page, and added a Chrome screenshot to the HTML <progress> element, which isn’t implemented in Firefox yet.
• Ms2ger improved several HTML element pages.
• Miles Clark improved several CSS property pages, and expanded the examples for position and float.
• xakz and shgz translated several HTML-related pages into French.
• Addy Osmani fleshed out the Introduction to web development page, making it actually (and very) useful.
• shiawuen added an example to event.currentTarget.
• brianloveswords edited the JavaScript Getting Started article, and created a placeholder for aggregated compatibility information (which we need to figure out how to automatically populate).
• Tomislav Jovanovic enhanced the article on JavaScript strict mode. Unfortunately, we didn’t know that Jeff Walden was about to replace that page with the contents of the recent Hacks blog post about strict mode. Tomislav then added examples and other improvements to the post-Hacks version of the page.
• Florian Scholz continued his work from the October doc sprint, cleaning up the MathML reference pages, and adding the <multiscripts> element.
• Trevor Hobson updated a bunch of (that is, 11) XPCOM interface reference pages, something he works on regularly, doc sprint or no doc sprint.
• David Bruant, another doc sprint veteran, considerably expanded the JavaScript Proxy article.
• Eric Shepherd created templates for tagging items as applying to “mobile” only, for a button to “see this on JSFiddle”, and for embedding a rendered SVG image from an attached XML file. He also wrote documents related to Electrolysis content views and the Toolkit Profile Manager. And he reviewed and copy-edited many of the other articles written and updated during the sprint.
• Daniel Lopretto added examples to document.activeElement and document.anchors, provided alternatives for document.width and document.height, and expanded the example for CSS attribute selectors.
• Ryan Olson added a live example for CSS positioning, and added some descriptions to the HTML attribute table.
• Adam Dane created pages for <time> and <meter> HTML elements and fixed up syntax highlighting and indention of examples for about 50 HTML element pages.
• Andreas Wagner documented XPCOM interfaces for bug 606966, “Need an async history visit API exposed to JS”, updated Displaying Places information using views for bug 543444, and updated a few XPCOM interfaces for navigation history.
• Jussi Kalliokoski wrote Creating a simple synth, about using the Audio API.
• Matheus S. Svolenski and Fabricio Ferracioli each translated some articles into Portuguese.
• Janet Swisher finished updating the IndexedDB asynchronous API reference pages to match the current draft standard and Mozilla implementation.
• Garann Means updated parts of Rich Text Editing in Mozilla, added a JSON example to AJAX Getting Started, and added a section on clearing floats to the CSS float property. Since Garann and I live in the same city, we met on Saturday morning for some in-person doc sprinting.
• Mason Stewart added notes to the legacy attributes that have been replaced by CSS properties, in the HTML Attributes page, and proofread and fixed up several other pages.
• Alex Lakatos created live examples for the CSS properties background-repeat, background-position, and list-style.
• Archaeopteryx created the page documenting nsIAppStartup_MOZILLA_2_0.
• Christian Sonne updated gradient-related CSS properties to include browser compatibility information, added an example to clear, and summary, examples, and “see also” to :visited.
• Divya Manian added or updated browser compatibility information on over a dozen CSS pages.

Today encoding.com released a new service called vid.ly which is not yet another URL shortener, but actually a very impressive service for converting video.

One of the biggest annoyance of using HTML5 video is to convert your movie to various formats supported by different browsers. Vid.ly does this job for you: it converts the video you upload into 14 different formats for different browsers and, more importantly, devices. The interface is very intuitive and you can stand by and watch the conversion happen or simply let it run whilst you go offline or do other things. Once the service finished creating the different formats for you, you get an email. You then can visit the vid.ly URL on different devices and you get the video in the correct format.

Interview with Jeff Malkin about vid.ly

To learn more about the service, I got Jeff Malkin, president of Encoding.com on the phone and asked him a few things about the service. You can listen to the interview:

In the interview Jeff answered a few questions and explained a few of my concerns:

• Vid.ly uses the same cloud backend as encoding.com, consisting of Amazon’s EC2 and S3 services and fallbacks
• The conversion happens with ffmpeg and a few other, commercial products as vid.ly also creates a high quality FLV for you
• The videos are tested on the real devices and they are also using services that give them access to more exotic physical devices on demand
• In addition to simply converting the videos to MP4 and Ogg (which can be done using Archive.org), vid.ly also creates iOS versions that support adaptive streaming and webm versions.
• There is no API to make part of a build process in the free version but they are working on a pro version that will allow you to batch process videos and have more granular access to the encoding parameters
• Right now, you can’t send the converted videos back to a hosting platform of your own choice but this is also in the making.

First impressions

When trying out the service with a video, I was very impressed with the interface. After entering your code you get a video URL. Pressing start asks you for an email (to notify you once the conversion is done) and offers you an interface to upload your video, either from FTP, HTTP, S3 or your hard drive. A log on the page tells you at any time what is happening:

The whole page is a progress bar. Once you uploaded the video the progress starts from left to right and tells you in the log box what is going on. You can stand by or close the page – vid.ly emails you once the conversion is done.

Under the hood

Once the conversion is done, you get the email with your URL and you can try it on different devices. I checked it on my Nexus One and my iPod and got working videos on each without any redirect, ad display or other annoyances.

The embed code vid.ly sends you can be improved a bit but was built for ease of use:

<video id="vidly-video" controls="controls" 
width="640" height="390">
<source
src="http://vid.ly/{ID}?content=video" />
<script id="vidjs" language="javascript" 
src="http://m.vid.ly/js/html5.js">
</script>
</video>

Instead of linking the different sources, vid.ly adds a JavaScript that re-writes the source accordingly. If you check the script you see that it includes the VideoJS player by Zencoder and that there is a lot of detection going on – both using the HTML5 Video API and browser sniffing for Quicktime support or to fall back to Flash.

This seems a bit overkill and could be improved. The other annoyance are IDs on the video and script as that prevents you from using several vid.ly videos in the same document. But then again, the power of open tech is that you can work around that:

The email is that it tells you that there is a high quality FLV file created for you at http://vidly.s3.amazonaws.com/{ID}/flv.flv. This means that your videos are stored in Amazon’s S3 with a bucket with the ID of your video. If you rename the flv.flv to ogv.ogv, webm.webm and mp4/mp4 accordingly you use these URLs to create your own video embed without JavaScript or you can download the different versions.

Try it out yourself

You can try vid.ly yourself using the HNY2011 code. What do you think?

The source of the code examples in this post is available on GitHub and you can see the demo in action.

There are dozens of video players that allow you to do all the normal things with videos: play, pause, jump to a certain time and so on. More advanced ones also allow you to fast forward and reverse the video and support subtitles.

One thing I haven’t found yet though is zooming and rotation of a video. Granted, an edge use case, but sometimes it is cool to be able to zoom into a detail like a blooper (boom mic in the background) or an easter egg (check for the term “A 113″ in every Pixar movie – an homage to the classroom most of the original Pixar cast learned their trade in).

Rotation might come in handy when you recorded your video in portrait instead of landscape on your camera and you don’t want to re-encode it before you put it on the web.

The HTML5 video tag allows you to style the video with CSS and CSS3 transforms allow both for scaling and for rotation. So let’s put those together.

Embedding a video is as simple as this (see this in action on the demo page):

<video controls>
  <source src="http://www.archive.org/download/AnimatedMechanicalArtPiecesAtMit/P1120973_512kb.mp4" type="video/mp4">         
  <source src="http://www.archive.org/download/AnimatedMechanicalArtPiecesAtMit/P1120973.ogv" type="video/ogg">
  <p>Your browser doesn't support the HTML5 video tag it seems. 
     You can see this video as part of a collection <a href="http://www.archive.org/download/AnimatedMechanicalArtPiecesAtMit/">at archive.org</a>.</p>         
</video>

Now, to scale this video you can use CSS3 transform:scale:

video{
  display:block;
  width:400px;
  height:300px;
}
video.scale2{
  -moz-transform:scale(1.5);
  -webkit-transform:scale(1.5);
  -o-transform:scale(1.5);
  -ms-transform:scale(1.5);
  transform:scale(1.5);
}

You can rotate with CSS3 transform:rotate:

video{
  -moz-transform:rotate(20deg);
  -webkit-transform:rotate(20deg);
  -o-transform:rotate(20deg);
  -ms-transform:rotate(20deg);
  transform:rotate(20deg);
}

And you can do both:

video{
  -moz-transform:scale(1.5) rotate(20deg);
  -webkit-transform:scale(1.5) rotate(20deg);
  -o-transform:scale(1.5) rotate(20deg);
  -ms-transform:scale(1.5) rotate(20deg);
  transform:scale(1.5) rotate(20deg);
}

Now, this doesn’t make much sense though as it changes the dimension of the video (in the demo page I needed to change the margin for each video accordingly). To really provide a “zoom” functionality, we’d need to keep the original size and cut off the parts we don’t need. We could do this using a CANVAS element, but why go that far when a simple DIV does the job for us?

All we need to do to keep the space is nest our videos in a DIV with the class stage:

<div class="stage"><video controls>
  <source src="http://www.archive.org/download/AnimatedMechanicalArtPiecesAtMit/P1120973_512kb.mp4" type="video/mp4">         
  <source src="http://www.archive.org/download/AnimatedMechanicalArtPiecesAtMit/P1120973.ogv" type="video/ogg">         
  <p>Your browser doesn't support the HTML5 video tag it seems. 
     You can see this video as part of a collection <a href="http://www.archive.org/download/AnimatedMechanicalArtPiecesAtMit/">at archive.org</a>.</p>         
</video></div>

The CSS to make the cropping work is the following:

.stage{
  width:400px;
  height:300px;
  position:relative;
}
video{
  width:400px;
  height:300px;
  position:absolute;
  top:0;
  left:0;
}

Absolutely positioned elements are taken out of the normal flow of the document. If you put an absolutely positioned element inside one that is relatively positioned, its top and left values are relative to the other element. In other words: the video now covers the stage completely.

If we rotate the video we still have triangular spaces showing like in this example:

.demostage{
  width:400px;
  height:300px;
  position:relative;
}
.demovideo{
  position:absolute;
  top:0;
  left:0;
  -moz-transform:rotate(20deg);
  -webkit-transform:rotate(20deg);
  -o-transform:rotate(20deg);
  -ms-transform:rotate(20deg);
  transform:rotate(20deg);
  width:400px;
  height:300px;
}

To work around this, we must add a overflow:hidden to the stage DIV:

.demostage{
  width:400px;
  height:300px;
  position:relative;
  overflow:hidden;
}
.demovideo{
  position:absolute;
  top:0;
  left:0;
  -moz-transform:rotate(20deg);
  -webkit-transform:rotate(20deg);
  -o-transform:rotate(20deg);
  -ms-transform:rotate(20deg);
  transform:rotate(20deg);
  width:400px;
  height:300px;
}

In order to provide a zoom and rotate functionality, we need to use JavaScript and buttons for the end user. The first hurdle here is – as you probably already realised from the CSS – browser differences in the syntax. Therefore we need to detect which of the transformations the current browser supports. The safest way is to ask the browser:

var properties = ['transform', 'WebkitTransform', 'MozTransform',
                  'msTransform', 'OTransform'];
var prop = properties[0];
for(var i=0,j=properties.length;i<j;i++){
  if(typeof v.style[properties[i]] !== 'undefined'){
    prop = properties[i];
    break;
  }
}

Once this runs we can set a transformation with the following JavaScript syntax:

var zoom = 1.5;
var rotate = 20;
v.style[prop]='rotate('+rotate+'deg) scale('+zoom+')';

Of course it doesn’t make much sense to rotate the controls with the video. Therefore you need to provide your own. You can use any of the aforementioned players for that or roll your own. To demonstrate, I just built one with a single button allowing you to play and pause the video:

The full source is available on GitHub, read the comments to see what is going on here.

Just a quick example of what you can do with open technologies.