Articles for January 2011

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.

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.

Leggi la traduzione in italiano

Today we are featuring Rob Hawkes author of Rawkets, a multiplayer game using canvas and websockets.

Rob was one of the presenters at the Game On 2010 event in London, England where he showed off his game. The video and his slides are available on the Mozilla Games Blog. He is currently busy working on a book about Canvas. You can find Rob on Twitter as @robhawkes.

The message I really loved getting from Rob was that it is OK to use any technology you want and that there is a benefit to people messing around with your code – even if it is to game the system.

The video interview

You can see the video on any HTML5 enabled device here (courtesy of vid.ly).

Ten questions about HTML5 for Rob Hawkes

1) So, you’ve been fiddling around with Canvas for gaming a lot – why the fascination? Did you write games in other environments before?

I sure have. My life has practically revolved around making games of some sort for the past year or two now. I just love the concept of using games to experiment with a programming languages and really learn everything I can about them. It’s a good way to try out most of the features involved in visual programming as well, particularly with harder concepts like physics, which I’m still no expert in. My fascination with games programming started out of necessity really; I had to create a game in my second year of university, so I co-created an augmented reality game using Papervision3D and ActionScript. From there I co-created another game of sorts in Adobe Flex that allowed people to play against each other using a webcam, which was fun. And now I’m making games in canvas; partly because it’s fun, and partly to learn everything I can about it. I get a kick out of the interactivity and playability factor that games bring, which I think hooks into my addiction for visual programming in general.

2) The cool thing about open technologies is that it is easy to see what is going on under the hood. View source and you get the picture. For gaming, isn’t that a problem? To “game” a highscore for a Flash game at least you need to do some HTTP sniffing – with Canvas it must be even easier. How do you protect yourself from that?

The fact that canvas is so open is something that makes me interested in it. I’m usually pretty open about programming and I’d love it if people can learn from my code, so being able to view the source code directly within the browser is amazing for that. However, the major drawback is that your code is open for everyone to see, so security becomes a pretty big issue.

You’re right though, this is particularly troublesome with gaming, and I’m inclined to say that there isn’t much that you can do about it. In fact, is wasn’t long after I released the first version of Rawkets that people started to poke around the code and manipulate the game to their advantage.

In all honesty, I actually see it as a good thing, as it showed me where my code was weak, and highlighted the areas that I needed to secure. You can obfuscate and minify your code as much as you want, but people can still get access to it because it’s just the way JavaScript works. However, there are a few ways to mitigate the problem, like passing core logic for the game to a remote server and communicating to it via restrictive and secure API calls. This is a good method for multiplayer games, where data received from the server is seen as trustworthy, and where as data on the client side is not. Or, you can wrap sensitive code in closures and take advantage of local variables to hide away data that you don’t want people to easily access. Another option is to just not worry about it. So long as you don’t let the hackers ruin the game for other players, does it really matter if they screw it up in their own browser?

In reality, none of these methods will 100% protect you, but they’ll certainly make things harder for would-be hackers.

3) Talking about open. Isn’t Canvas just a Java applet with a predefined API and no need for a slow JVM? You still only have a rectangle somewhere in the page you can manipulate…

If you mean that canvas is like a sandbox that you can only access via a specific set of API calls, then yes, pretty much. Then again, the API calls allow you to do a hell of a lot, and couldn’t you say the same about Flash and all the closed methods of creating graphics?

I suppose when you say canvas is open; you’re mainly talking about the development behind its creation (ie. the W3C), and the fact that the code to draw elements on it isn’t hidden away from prying eyes. Canvas is definitely not open in the sense that you are free to extend it and do whatever you want with it. So long as you abide by the API calls, which is fine for 99% of the time, then you’ve not got a problem.

As you say, canvas is effectively just a rectangular area that the browser allows you to draw into. Once you’ve drawn a few shapes into it, you can’t access them individually, but then again, that’s exactly how canvas is meant to work. It’s not like SVG, where every element that you’ve drawn can be accessed from the DOM and edited. Canvas is a bitmap system that has no concept of individual elements. It’s a destructive system that basically just changes the colour of pixels within its rectangle, based on the API calls that you give it. In that way, it’s just like Microsoft Paint from back in the day.

4) What about accessibility? Can assistive technology access canvas content? How about keyboard access?

To put it bluntly, not really. At least, not yet.

Canvas does have fallback content, which is placed between the canvas tags and shows up when a browser doesn’t support canvas, but it doesn’t have much else to aid with accessibility. The cool thing about the fallback content is that it’s possible to place content in there for keyboard access. I believe IE9 already has this functionality, which lets you show the canvas, but still give keyboard access so you can describe what’s going in within the canvas in text, or something like that. The problem with methods like this is that you effectively duplicate all of your content; you draw everything on the canvas, and then you have to write it all up within the canvas tags to explain what you’ve drawn.

What you can’t do yet is give assistive access to individual elements within the canvas, simply because canvas is just a big rectangle of pixels with no concept about what’s bee drawn. This is the major drawback with using a bitmap system that has a pretty closed API. There is talk about using something called the shadow DOM, to open up the canvas and allow some sort of access into the elements that have been drawn, but I don’t believe much has been done about this yet.

It’s definitely an area that I’m interested to see progress, but in the meantime, Bruce Lawson highlights a couple of the proposals that are floating around to sort out the accessibility issue with canvas.

5) What about performance? What are the hot tips to keep a canvas game run smoothly?

This is a massive sticking point with canvas at the moment; it can be so god damn slow! Actually, this isn’t really a problem with canvas, but rather the fact that canvas uses the browser process to draw everything, which in turn uses the processor (CPU).

Some browsers are introducing something called hardware acceleration, which passes off canvas and graphical processes to the graphics card (GPU). This simple feature really speeds things up, and allows you to do some pretty intensive stuff. Still, hardware acceleration isn’t a magic bullet; you still need to program defensively and be aware of potential bottlenecks and performance issues with your code.

The most common issues arise around unnecessarily extravagant timers and loops. For example, animating in canvas usually requires the use of a JavaScript timeout, which runs a function that draws everything onto the canvas 30 times a second; fast enough to look like things are moving. This is great, but what about if you’re not animating things any more? I’ve made the mistake of not turning off the animation timer, and inherently sucking precious CPU juice for no good reason.

Another example is that of collision detection, or any other check that has to be performed on a large amount of objects. The bad way of doing this is to loop through every object, and then loop through every object a second time on each iteration of the original loop. The problem with this is that you end up checking some objects twice, or more, and basically wasting resources. Instead, you can optimise your loops to ignore objects that you’ve already checked, which can cut the amount of loops down considerably.

There are countless ways to optimise your code, and most won’t achieve much on their own, but together they can add up to save a pretty significant amount of resources.

6) Your game uses Web sockets for communication. How did you find that to work with? Does it scale well? Are there any things you don’t like about the technology?

You mean that it used to use WebSockets? It’s a shame FireFox and others decided it would be a great idea to drop support for them for the time being. Jesting aside, the game is built atop WebSockets, and it’s been an interesting journey. I love WebSockets, and I think that having a full-duplex method of communicating within a browser is fantastic. The fact that the data is streamed live opens up a whole range of possibilities for games and Web apps.

I didn’t find too many issues with WebSockets regarding stability and scalability, as in reality most of the problems lay with the code on the server that deals with sending information back and forth. I found that one thing you need to be aware of is that the amount of data being sent back and forth can increase at an exponential rate if you’re not used to optimising communication for a large amount of users.

I have to admit though, my biggest bug bear with WebSockets is that it sends data as text, and it doesn’t support the UDP protocol. Right now, WebSockets sending everything as text data is great because it’s dead simple, but it sucks because it can potentially take a lot of precious bandwidth, especially when you’re sending data many times a second to hundreds of different players in a game.

The UDP problems relates to how canvas currently only supports the TCP protocol. What this means is that every piece of data that is sent back and forth between a server and a client has to be received in order. This is not good for gaming, where a bit of lag can end up causing a backlog of messages that have to be sent in order before any new messages can be sent. UDP on the other hand would allow you to send messages as and when they occur, without worrying about order. This is very good for games that rely on precise data that is time-sensitive, like the movement of a player in an FPS game.

You have to remember that WebSockets is something new, and it’s likely to have some teething troubles at the beginning; hence it being disabled temporarily. Still, it’s got a bright future, and I’m looking forward to seeing how it progresses.

7) Have you played with SVG, too? If so, when would you use what and is there a chance to use the strong parts of both technologies together?

Admittedly, I’ve not played with SVG as much as I’d like to. I’ve just become so caught up in the world of canvas in recent months. However, it’s something that I strongly believe should be used instead of canvas in particular circumstances, like when dealing with the conversion of existing HTML data into a graphical format (eg. creating graphs from a table).

SVG is also great because it’s accessible via the DOM, but it falls down with animation and gaming. It was never built with this kind of use in mind, and it’s exactly why canvas exists. Canvas is perfect for fast and dynamic animations, and it’s particularly perfect for creating games.

Fortunately, it isn’t always a case of being either or with SVG and canvas. It’s completely possible to draw SVG shapes within canvas, which has the added benefit of letting you have all the vector goodness of SVG within a bitmap system. I’ve heard of people using techniques like this for sprites within games, and for drawing images onto canvas that need to be resized a lot.

8) What’s the next barrier you’d love to see opened up? What features of closed technology are there that are beyond your reach but you are itching to try out?

I’m really interested in seeing the Device APIs (DAP) being supported in the major browsers. One of the things that is lacking in browsers at the moment is support for external devices like webcams and microphones. I can just see canvas and DAP being used together for some pretty awesome Web apps and visualisations. Imagine being able to create an avatar for a website by using a bit of canvas with an attached webcam. Or, what about live video chat through the browser with WebSockets and canvas/HTML5 video? That would be JavaScript awesomeness right there!

9) Currently you’re writing a book on Canvas. As not everybody has time to wait for this, where could people go in the meantime to get the real info about starting with canvas?

It’s not a massive wait (it’ll be out in May), but in the meantime I’d suggest going to the Mozilla Developer Network. It’s where I learnt how to use canvas, so it must be good! Apart from that, there really is a lack of decent resources for learning canvas at the moment, but I predict that changing for the better over the next year.

10) Where could people go to get inspiration? What other uses of Canvas have you seen that made you go “woooo I want that!”?

There are some fantastic projects being created with canvas at the moment. I could create a massive list, but here are some of my favourite:

• Mozilla Game On
• Biolab Disaster
• David Desandro’s portfolio
• Paul Truong
• Hakim El Hattab
• Silk

Some particularly impressive uses of canvas that have got my juices flowing are projects that really push the pixel manipulation features of canvas, like using it to detect faces in images, or nudity. Weird, but pretty impressive stuff!

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

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.)

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?

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.)

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.

As part of our university outreach programme, a few Mozilla people and volunteers went to Boston last week to give a series of lectures on web technologies for games development.

During the week we covered topics like WebGL for 3D development, basics of JavaScript, debugging and performance, canvas development, offline development and local storage and multimedia on the web. We’ll make these slides available in the comments to this blog post.

The slides of the multimedia talk are available here:

The topics covered were:

• Quick history of Multimedia on the web
• Annoyances with Flash
• HTML5 audio and video
• Codecs and conversion
• Embedding video and audio
• Controlling video
• Transforming video
• Making realtime changes
• Awesome new audio possibilities

We showed and explained a few demos like:

• The Media events demo page at the W3C web site
• The Spirit of Indiana demo syncing a Google Maps animation with a video
• Transforming Video to create a player that allows you to zoom inside a video and rotate it using CSS transformations
• Paul Rouget’s round video demo showing how to create a play/pause button in SVG, greyscale a video and rotate it using CSS transformations
• Paul’s Video Mashup demo showing how to apply SVG filters like Gaussian Blur, masking and how to apply CSS transforms to a running video
• Remy Sharp’s round video demo showing how to create a rotating, bouncing circle that contains a video
• Paul Rouget’s Green demo showing how to simulate a green screen effect with open web technologies.
• The dynamic content injection demo showing how to embed content into a video after analysing it for injection hotspots.
• The Tracker demo showing how to detect human shapes and movement in a video
• The edge detection demo shows how to detect edges in a live video using JavaScript
• The HTML5 Guitar Tab generator
• The sfxr sound effect library

I also provided extensive notes for the whole talk with code examples on my own blog.

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.

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!

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.

Leggi la traduzione in italiano

Today we are featuring Remy Sharp co-author of Introducing HTML5 and organiser of the Full Frontal conference in Brighton, England.

Remy is one of those ubiquitous people of HTML5. Whenever something needed fixing, there is probably something on GitHub that Remy wrote that helps you. He is also very English and doesn’t mince his words much.

You can find Remy on Twitter as @rem.

The video interview

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

Ten questions about HTML5 for Remy Sharp

1) Reading “Introducing HTML5″ it seems to me that you were more of the API – focused person and Bruce the markup guy. Is that a fair assumption? What is your background and passion?

That’s spot on. Bruce asked me to join the project as the “JavaScript guy” – which is the slogan I wear under my clothes and frequently reveal in a superman ‘spinning around’ fashion (often at the surprise of clients).

My background has always been coding – even from a young age, my dad had me copying out listings from old spectrum magazines only to result in hours of typing and some random error that I could never debug.

As I got older I graduated to coding in C but those were the days the SDKs were 10Mb downloaded over a 14kb modem, and compile in to some really odd environment. Suffice to say I didn’t get very far.

Then along came JavaScript. A programming language that didn’t require any special development environment. I could write the code in Notepad on my dodgy Window 95 box, and every machine came with the runtime: the browser. Score!

From that point on the idea of instant gratification from the browser meant that I was converted – JavaScript was the way for me.

Since then I’ve worked on backend environments too (yep, I’m a Perl guy, sorry!), but always worked and played in the front end in some way or another. However, since started on my own in 2006, it’s allowed me to move focus almost entirely on the front end, and specialise in JavaScript. Basically, work-wise: I’m a pig in shit [Ed: for our non-native English readers, he means "happy")].

2) From a programmer’s point of view, what are the most exciting bits about the HTML5 standard? What would you say is something every aspiring developer should get their head around first?

For me, the most exciting aspects of HTML5 is the depth of the JavaScript APIs. It’s pretty tricky to explain to Joe Bloggs that actually this newly spec’ed version of HTML isn’t mostly HTML; it’s mostly JavaScript.

I couldn’t put my finger on one single part of the spec, only because it’s like saying which is your favourite part of CSS (the :target selector – okay, so I can, but that’s not the point!). What’s most exciting to me is that HTML5 is saying that the browser is the platform that we can deliver real applications – take this technology seriously.

If an aspiring developer wanted something quick and impressive, I’d say play around with the video API – by no means is this the best API, just an easy one.

If they really wanted to blow people away with something amazing using HTML5, I’d say learn JavaScript (I’m assuming they’re already happy with HTML and CSS). Get a book like JavaScript: The Good Parts and then get JavaScript Patterns and master the language. Maybe, just maybe, then go buy Introducing HTML5, it’s written by two /really/ good looking (naked) guys: http://flic.kr/p/8iyQTE and http://flic.kr/p/8iy6Z1 [Ed: maybe NSFW, definitely disturbing].

3) In your book you wrote a nice step-by-step video player for HTML5 video. What do you think works well with the Video APIs and what are still problems that need solving?

The media API is dirt simple, so it means working with video and audio is a doddle. For me, most of it works really well (so long as you understand the loading process and the events).

Otherwise what’s really quite neat, is the fact I can capture the video frames and mess with them in a canvas element – there’s lots of fun that can be had there (see some of Paul Rouget’s demos for that!).

What sucks, and sucks hard, is the spec asks vendors, ie. browser makers, *not* to implement full screen mode. It uses security concerns as the reason (which I can understand), but Flash solved this long ago – so why not follow their lead on this particular problem? If native video won’t go full screen, it will never be a competitive alternative to Flash for video.

That all said, I do like that the folks behind WebKit went and ignored the spec, and implemented full screen. The specs are just guidelines, and personally, I think browsers should be adding this feature.

4) Let’s talk a bit about non-HTML5 standards, like Geolocation. I understand you did some work with that and found that some parts of the spec work well whilst others less so. Can you give us some insight?

On top of HTML5 specification there’s a bunch more specs that make the browser really, really exciting. If we focus on the browser being released today (IE9 included) there’s a massive amount that can be done that we couldn’t do 10 years ago.

There’s the “non-HTML5″ specs that actually were part of HTML5, but split out for good reason (so they can be better managed), like web storage, 2D canvas API and Web Sockets, but there’s also the /really/ “nothing-to-do-with-HTML5″ APIs (NTDWH5API!) like querySelector, XHR2 and the Device APIs. I’m super keen to try all of these out even if they’re not fully there in all the browsers.

Geolocation is a great example of cherry picking technology. Playing against the idea that the technology isn’t fully implemented. Something I find myself ranting on and on about when it comes to the question of whether a developer should use HTML5. Only 50% of Geolocation is implemented in the browsers supporting it, in that they don’t have altitude, heading or speed – all of which are part of the spec. Does that stop mainstream apps like Google Maps from using the API? (clue: no).

The guys writting the specs have done a pretty amazing job, and in particular there are few cases where the specs have been retrospectively written. XHR is one of these and now we’ve got a stable API being added in new browsers (i.e. IE6 sucks, yes, we all know that). Which leads us to drag and drop. The black sheep of the APIs. In theory a really powerful API that could make our applications rip, but the technical implementation is a shambles. PPK (Peter-Paul Koch) tore the spec a bit of a ‘new one’. It’s usable, but it’s confusing, and lacking.

Generally, I’ve found the “non-HTML5″ specs to be a bit of mixed bag. Some are well supported in new browsers, some not at all. SVG is an oldie and now really viable with the help of JavaScript libraries such as Raphaël.js or SVGWeb (a Flash based solution). All in all, there’s lots of options available in JavaScript API nowadays compared to back in the dark ages.

5) Let’s talk Canvas vs. SVG for a bit. Isn’t Canvas just having another pixel-based rectangle in the page much like Java Applets used to be? SVG, on the other hand is Vector based and thus would be a more natural tool to do something with open standards that we do in Flash now. When would you pick SVG instead of Canvas and vice versa?

Canvas, in a lot of ways is just like the Flash drawing APIs. It’s not accessible and a total black box. The thing is, in the West, there’s a lot of businesses, rightly or wrongly, that want their fancy animation thingy to work on iOS. Since Flash doesn’t work there, canvas is a superb solution.

However, you must, MUST, decide which technology to use. Don’t just use canvas because you saw a Mario Kart demo using it. Look at the pros and cons of each. SVG and the canvas API are not competitive technologies, they’re specially shaped hammers for specific jobs.

Brad Neuberg did a superb job of summarising the pros and cons of each, and I’m constantly referring people to it (here’s the video).

So it really boils down to:

• Canvas: pixel manipulation, non-interactive and high animation
• SVG: interactive, vector based

Choose wisely young padawan!

6) What about performance? Aren’t large Canvas solutions very slow, especially on mobile devices? Isn’t that a problem for gaming? What can be done to work around that?

Well…yes and no. I’m finishing a project that has a large canvas animation going on, and it’s not slow on mobile devices (not that it was designed for those). The reason it’s not slow is because of the way the canvas animates. It doesn’t need to be constantly updating at 60fps.

Performance depends on your application. Evaluate the environment, the technologies and make a good decision. I personally don’t think using a canvas for a really high performance game on a mobile is quite ready. I don’t think the devices have the ommph to get the job done – but there’s a hidden problem – the browser in the device isn’t quite up to it. Hardware acceleration is going to help, a lot, but today, right now, I don’t think we’ll see games like Angry Birds written in JavaScript.

That said… I’ve seriously considered how you could replicate a game like Canabalt using a mix of canvas, DIVs and CSS. I think it might be doable ::throws gauntlet::

I think our community could actually learn a lot from the Flash community. They’ve been through all of this already. Trying to make old versions of Flash from years back do things that were pushing the boundaries. People like Seb Lee-Delisle (@seb_ly / http://seb.ly) are doing an amazing job of teaching both the Flash and JavaScript community.

7) A feature that used to be HTML5 and is now an own spec is LocalStorage and its derivatives Session Storage or the full-fledged WebSQL and IndexedDB. Another thing is offline storage. There seems to be a huge discussion in developer circles about what to use when and if NoSQL solutions client side are the future or not. What are your thoughts? When can you use what and what are the drawbacks?

Personally I love seeing server-less applications. Looking at the storage solutions I often find it difficult to see why you wouldn’t use WebStorage every time.

In a way it acts like (in my limited experience of) NoSQL, in that you lookup a key and get a result.

Equally, I think SQL in the browser is over the top. Like you’re trying to use the storage method *you* understand and forcing it into the browser. Seems like too much work for too little win.

Offline Apps, API-wise, ie. the application cache is /really/ sexy. Like sexy with chocolate on top sexy. The idea that our applications can run without the web, or switch when it detects it’s offline is really powerful. The only problem is that the events are screwed. The event to say your app is now offline requires the user to intervene via the browser menu, telling the browser to “work in offline mode”. A total failure of experience. What’s worse is that, as far as I know, there’s no plan to make offline event fire properly :-(

That all said, cookies are definitely dead for me. I’ve yet to find a real solution for cookies since I found the Web Storage API – and there’s a good decent number of polyfills for Web Storage – so there’s really no fear of using the API.

8) Changing the track a bit, you’ve built the HTML5shiv to make HTML5elements styleable in IE. This idea sparked quite a lot of other solutions to make IE6 work with the new technologies (or actually simulate them). Where does this end? Do you think it is worth while to write much more code just to have full IE6 support?

There’s two things here:

1. Supporting IE6 (clue: don’t)
2. Polyfills

IE6, seriously, and for the umpteenth time, look at your users. Seriously. I know the project manager is going to say they don’t know what the figures are, in that case: find out! Then, once you’ve got the usage stats in hand, you know your audience and you know what technology they support.

If they’re mostly IE6 users, then adding native video with spinning and dancing canvas effect isn’t going to work – not even with shims and polyfills. IE6 is an old dog that just isn’t up to doing the mileage he used to be able to do back in his prime. But enough on this subject – the old ‘do I, or don’t I developer for IE6′ is long in the tooth.

Polyfills – that’s a different matter. They’re not there to support IE6, they’re there to bring browsers up to your expectations as a developer. However, I’d ask that you carefully consider them before pulling them in. The point of these scripts is they plug missing APIs in those older browsers. “Old browsers” doesn’t particularly mean IE6. For example, the Web Sockets API has a polyfill by way of Flash. If native Web Sockets aren’t there, Flash fills the gap, but the API is exposed in exactly the same manner, meaning that you don’t have to fork your code.

I don’t think people should be pulling in scripts just for the hell of it. You should consider what you’re trying to achieve and decide whether X technology is the right fit. If it is, and you know (or expect) your users have browsers that don’t support X technology – should you plug it with JavaScript or perhaps should you consider a different technology?

This exact same argument rings true for when someone adds jQuery just to add or remove a class from an element. It’s simply not worth it – but clearly that particular developer didn’t really understand what they needed to do. So is education the solution? I should hope so.

9) Where would you send people if they want to learn about HTML5? What are tutorials that taught you a lot? Where should interested people hang out?

HTML5 Doctor – fo sho’. :)

I tend to also direct people to my http://html5demos.com simply to encourage viewing source, and hacking away.

Regarding what tutorials taught me – if I’m totally honest, the place I’ve learnt the most from is actually HTML5Doctor.com. There’s some pretty good JavaScript / API tutorials coming from the chaps at http://bocoup.com. Otherwise, I actually spend a lot of time just snooping through the specifications, looking for bits that I’ve not seen before and generally poking them with a stick.

10) You have announced that you are concentrating on building a framework to make Websockets easy to work with. How is that getting on and what do you see Websockets being used for in the future? In other words, why the fascination?

Concentrating is a strong word ;-) but it is true, I’ve started working on a product that abstracts Web Sockets to a service. Not the API alone, since it’s so damn simple, but the server setup: creating sessions, user control flow, waiting for users and more.

The service is called Förbind. Swedish for “connect”, ie. to connect your users. It’s still early days, but I hope to release alpha access to forbind.net this month.

I used to work in finance web sites and real-time was the golden egg: to get that data as soon as it was published. So now that it’s available in a native form in the browser, I’m all over it!

What’s more, I love the idea of anonymous users. I created a bunch of demos where the user can contribute to something without ever really revealing themselves, and when the users come, you start to see how creative people are without really trying. Sure, you get a lot of cocks being drawn, but you also see some impressive ideas – my business 404 page for example allows people to leave a drawing, one of the most impressive is a Super Mario in all his glory. Anonymous users really interest me because as grey as things can seem sometimes, a stranger can easily inspire you.

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