Articles for December 2011

We have now released Aurora 11, soon to become Firefox 11, and wanted to cover all the the things we have improved in this version!

Continued…

More Goodies for the Holidays!

Last month, I wrote a post for Hacks introducing the new tools in Firefox 10 Aurora. Those features have now moved to beta. Thanks for all of the great feedback so far!

In a dramatic turn at the end of that blog post, I foreshadowed that we had “more to come”. And, indeed here I am to tell you about the new developer tools features now in Firefox Aurora. What you see here is slated for final release in March, 2012.

Free-form Style Sheet Editing

In the last Firefox release, we introduced the Style Inspector. You can use the Style Inspector’s rules view to make changes to the CSS properties for an element. With this release, we’re adding a free-form Style Editor to the mix.

Select the Style Editor from the Web Developer menu, and you’re presented with a view that lists the style sheets for the page in one pane, and gives you an editor to make changes in another:

The Style Editor provides a friendly environment for working on your style sheets. Any changes you make are reflected instantly on the page. Once you’ve made your changes, you can save the file on your computer.

There are also a number of handy additional features. Click on the “eye” icon next to the style sheet and you can toggle the entire sheet on and off. If you’re working on a new page, you can create new style sheets on the fly or load a style sheet from disk.

If you want to take a look at how other sites on the web are styled, you can use the Style Editor to view the style sheets on any site. On public sites, the style sheets are often minified to reduce download time. The Style Editor will automatically prettify style sheets that it detects have been minified, but it will leave your source style sheets alone.

“Tilt” 3D View of Web Page Structure

Open up the Page Inspector (Web Developer->Inspect from the menu, or Inspect Element in the context menu on the page), and you’ll see a new 3D button on the toolbar if your computer is compatible with WebGL. Click that, and you’re presented with a whole new perspective on web page structure.

This 3D view (which was previously available in an add-on called Tilt), stacks elements as they are nested in the DOM and lets you see elements that are hidden or off the page. You can zoom in and out, rotate and pan the view to see the page from any angle that is helpful to you.

The 3D view is fully integrated with the rest of the Page Inspector functionality. You can open the HTML view or the Style Inspector for more information about the element you’ve clicked on in the 3D view. You can also change selected elements using the breadcrumbs on the toolbar.

The controls for the 3D view are easy:

Dozens of Other Improvements

Since the last release, we’ve landed dozens of refinements to our other developer features. A growing number of contributors are making the tools they use better by getting involved.

The Web Console, Scratchpad and Style Inspector have all had improvements since the last Firefox. Take a look, and let us know what you think!

Get it Now!

You don’t need to wait until March to get these great new features. Download Firefox Aurora today and see these and other improvements that are coming to final release soon.

Updates+Screencast

Since I wrote this article, we’ve landed some fixes and improvements to these tools. I added the way to pan the Page Inspector 3D view (right-click and drag). Also, there is now a screencast for these features. Be sure to opt-in to YouTube’s HTML5 video option.

The Mozilla Labs Apps project

The Mozilla Labs Apps project enters a new phase with today’s launch of the Apps Developer Preview and App Development documentation in the Apps Developer Community on MDN.

The tools and resources in the MDN Apps Developer Community documentation enable developers to create rich, cross-platform and cross-device app experiences using web standards and open technologies such as HTML5, CSS and JavaScript. The Mozilla Labs Apps project also aims to create a rich distributed ecosystem of app stores including a Mozilla HTML5 app marketplace to launch in 2012.

To get started, sign up for the Mozilla Labs Apps Developer Preview, where you can test the features of the marketplace app-submission and sale process. The preview is limited to 3,000 developers on a first-come, first-served basis, so be sure to reserve your spot now.

Visit apps-preview.mozilla.org to register now.

If you are a Firefox user, please install the Mozilla Labs App Runtime Add-on, and if you are an Android user, please install the Mozilla Labs App Runtime application before you sign up for the Developer Preview. If you currently do not use Firefox or Android, go directly to the Apps Developer Preview.

Your installed HTML5 apps can be found at myapps.mozillalabs.com

Why is Mozilla focusing on apps?

As part of Mozilla’s mission to make the web better we believe that apps should be available on any modern web-connected device, operating system or browser, allowing billions of people worldwide to use and interact with apps.

Today, apps are tied to closed ecosystems. Apps also can’t be used across all devices; data within apps is silo-ed and inaccessible to other apps or Web services; and user choice is limited and undervalued.

In an open ecosystem, developers should have the ability to build apps using open Web technologies and resources. They should then be able to distribute and sell those apps with the reach, flexibility and choice that the Web provides.

Edit: See the section about Endiannes.

Typed Arrays can significantly increase the pixel manipulation performance of your HTML5 2D canvas Web apps. This is of particular importance to developers looking to use HTML5 for making browser-based games.

This is a guest post by Andrew J. Baker. Andrew is a professional software engineer currently working for Ibuildings UK where his time is divided equally between front- and back-end enterprise Web development. He is a principal member of the browser-based games channel #bbg on Freenode, spoke at the first HTML5 games conference in September 2011, and is a scout for Mozilla’s WebFWD innovation accelerator.

Eschewing the higher-level methods available for drawing images and primitives to a canvas, we’re going to get down and dirty, manipulating pixels using ImageData.

Conventional 8-bit Pixel Manipulation

The following example demonstrates pixel manipulation using image data to generate a greyscale moire pattern on the canvas.

Let’s break it down.

First, we obtain a reference to the canvas element that has an id attribute of canvas from the DOM.

var canvas = document.getElementById('canvas');

The next two lines might appear to be a micro-optimisation and in truth they are. But given the number of times the canvas width and height is accessed within the main loop, copying the values of canvas.width and canvas.height to the variables canvasWidth and canvasHeight respectively, can have a noticeable effect on performance.

var canvasWidth  = canvas.width;
var canvasHeight = canvas.height;

We now need to get a reference to the 2D context of the canvas.

var ctx = canvas.getContext('2d');

Armed with a reference to the 2D context of the canvas, we can now obtain a reference to the canvas’ image data. Note that here we get the image data for the entire canvas, though this isn’t always necessary.

var imageData = ctx.getImageData(0, 0, canvasWidth, canvasHeight);

Again, another seemingly innocuous micro-optimisation to get a reference to the raw pixel data that can also have a noticeable effect on performance.

var data = imageData.data;

Now comes the main body of code. There are two loops, one nested inside the other. The outer loop iterates over the y axis and the inner loop iterates over the x axis.

for (var y = 0; y < canvasHeight; ++y) {
    for (var x = 0; x < canvasWidth; ++x) {

We draw pixels to image data in a top-to-bottom, left-to-right sequence. Remember, the y axis is inverted, so the origin (0,0) refers to the top, left-hand corner of the canvas.

The ImageData.data property referenced by the variable data is a one-dimensional array of integers, where each element is in the range 0..255. ImageData.data is arranged in a repeating sequence so that each element refers to an individual channel. That repeating sequence is as follows:

data[0]  = red channel of first pixel on first row
data[1]  = green channel of first pixel on first row
data[2]  = blue channel of first pixel on first row
data[3]  = alpha channel of first pixel on first row
 
data[4]  = red channel of second pixel on first row
data[5]  = green channel of second pixel on first row
data[6]  = blue channel of second pixel on first row
data[7]  = alpha channel of second pixel on first row
 
data[8]  = red channel of third pixel on first row
data[9]  = green channel of third pixel on first row
data[10] = blue channel of third pixel on first row
data[11] = alpha channel of third pixel on first row
 
 
...

Before we can plot a pixel, we must translate the x and y coordinates into an index representing the offset of the first channel within the one-dimensional array.

        var index = (y * canvasWidth + x) * 4;

We multiply the y coordinate by the width of the canvas, add the x coordinate, then multiply by four. We must multiply by four because there are four elements per pixel, one for each channel.

Now we calculate the colour of the pixel.

To generate the moire pattern, we multiply the x coordinate by the y coordinate then bitwise AND the result with hexadecimal 0xff (decimal 255) to ensure that the value is in the range 0..255.

        var value = x * y & 0xff;

Greyscale colours have red, green and blue channels with identical values. So we assign the same value to each of the red, green and blue channels. The sequence of the one-dimensional array requires us to assign a value for the red channel at index, the green channel at index + 1, and the blue channel at index + 2.

        data[index]   = value;	// red
        data[++index] = value;	// green
        data[++index] = value;	// blue

Here we’re incrementing index, as we recalculate it with each iteration, at the start of the inner loop.

The last channel we need to take into account is the alpha channel at index + 3. To ensure that the plotted pixel is 100% opaque, we set the alpha channel to a value of 255 and terminate both loops.

        data[++index] = 255;	// alpha
    }
}

For the altered image data to appear in the canvas, we must put the image data at the origin (0,0).

ctx.putImageData(imageData, 0, 0);

Note that because data is a reference to imageData.data, we don’t need to explicitly reassign it.

The ImageData Object

At time of writing this article, the HTML5 specification is still in a state of flux.

Earlier revisions of the HTML5 specification declared the ImageData object like this:

interface ImageData {
    readonly attribute unsigned long width;
    readonly attribute unsigned long height;
    readonly attribute CanvasPixelArray data;
}

With the introduction of typed arrays, the type of the data attribute has altered from CanvasPixelArray to Uint8ClampedArray and now looks like this:

interface ImageData {
    readonly attribute unsigned long width;
    readonly attribute unsigned long height;
    readonly attribute Uint8ClampedArray data;
}

At first glance, this doesn’t appear to offer us any great improvement, aside from using a type that is also used elsewhere within the HTML5 specification.

But, we’re now going to show you how you can leverage the increased flexibility introduced by deprecating CanvasPixelArray in favour of Uint8ClampedArray.

Previously, we were forced to write colour values to the image data one-dimensional array a single channel at a time.

Taking advantage of typed arrays and the ArrayBuffer and ArrayBufferView objects, we can write colour values to the image data array an entire pixel at a time!

Faster 32-bit Pixel Manipulation

Here’s an example that replicates the functionality of the previous example, but uses unsigned 32-bit writes instead.

NOTE: If your browser doesn’t use Uint8ClampedArray as the type of the data property of the ImageData object, this example won’t work!

The first deviation from the original example begins with the instantiation of an ArrayBuffer called buf.

var buf = new ArrayBuffer(imageData.data.length);

This ArrayBuffer will be used to temporarily hold the contents of the image data.

Next we create two ArrayBuffer views. One that allows us to view buf as a one-dimensional array of unsigned 8-bit values and another that allows us to view buf as a one-dimensional array of unsigned 32-bit values.

var buf8 = new Uint8ClampedArray(buf);
var data = new Uint32Array(buf);

Don’t be misled by the term ‘view’. Both buf8 and data can be read from and written to. More information about ArrayBufferView is available on MDN.

The next alteration is to the body of the inner loop. We no longer need to calculate the index in a local variable so we jump straight into calculating the value used to populate the red, green, and blue channels as we did before.

Once calculated, we can proceed to plot the pixel using only one assignment. The values of the red, green, and blue channels, along with the alpha channel are packed into a single integer using bitwise left-shifts and bitwise ORs.

        data[y * canvasWidth + x] =
            (255   << 24) |	// alpha
            (value << 16) |	// blue
            (value <<  8) |	// green
             value;		// red
    }
}

Because we’re dealing with unsigned 32-bit values now, there’s no need to multiply the offset by four.

Having terminated both loops, we must now assign the contents of the ArrayBuffer buf to imageData.data. We use the Uint8ClampedArray.set() method to set the data property to the Uint8ClampedArray view of our ArrayBuffer by specifying buf8 as the parameter.

imageData.data.set(buf8);

Finally, we use putImageData() to copy the image data back to the canvas.

Testing Performance

We’ve told you that using typed arrays for pixel manipulation is faster. We really should test it though, and that’s what this jsperf test does.

At time of writing, 32-bit pixel manipulation is indeed faster.

Wrapping Up

There won’t always be occasions where you need to resort to manipulating canvas at the pixel level, but when you do, be sure to check out typed arrays for a potential performance increase.

EDIT: Endianness

As has quite rightly been highlighted in the comments, the code originally presented does not correctly account for the endianness of the processor on which the JavaScript is being executed.

The code below, however, rectifies this oversight by testing the endianness of the target processor and then executing a different version of the main loop dependent on whether the processor is big- or little-endian.

A corresponding jsperf test for this amended code has also been written and shows near-identical results to the original jsperf test. Therefore, our final conclusion remains the same.

Many thanks to all commenters and testers.

In this post I’ll be introducing the Gamepad and Mouse Lock APIs, two additions to Firefox that are paving the way for high quality games on the Web.

Continued…

In this post I give a quick overview of the Mozilla Labs Apps project and how it and the other technologies at Mozilla relate to gaming. We really are at a point where amazing games can be created on the Web with nothing but open technologies.

A few days ago we launched the developer preview of the Mozilla Labs Apps project, our vision of a distributed Web application platform. This apps project is directly related to our overall mission to better the Web, as recently described by Ragavan Srinivasan:

As part of Mozilla’s mission to make the Web better we believe that apps should be available on any modern Web-connected device, operating system or browser, allowing billions of people worldwide to use and interact with apps.

Today, apps are tied to closed ecosystems. Apps also can’t be used across all devices; data within apps is silo-ed and inaccessible to other apps or Web services; and user choice is limited and undervalued.

In an open ecosystem, developers should have the ability to build apps using open Web technologies and resources. They should then be able to distribute and sell those apps with the reach, flexibility and choice that the Web provides.

It’s important to remember that although we often talk about apps as pieces of software that each serve a particular task, they can also be games. After all, if you pull away the story and graphics, a game is really no different to what you would normally consider as an application — it uses the same platform and programming languages, HTML and JavaScript in this case.

So how does the Mozilla Labs Apps project and the other technologies that we’re working on relate to open Web games? I hope to shed some light on this question in the brief overviews that follow.

Rest assured, Mozilla is very much focused on making the Web a better platform for open Web gaming.

Identifying players with BrowserID

Just like how iOS has services like OpenFeint and the Apple Game Center, games on the Web need open and reliable methods of identifying players. BrowserID is one of our solutions to this problem. It allows players to log into your game using their existing email address, providing a password only once per browser session.

Implementing BrowserID within your game is a simple 3-step process. I advise you to check out the documentation about installation, where you’ll also find some fancy BrowserID buttons to show your players that you support distributed authentication. Right now BrowserID is provided via a JavaScript library. However in the near-future it will be built into Firefox for a seamless experience.

Identifying players in this way is just the first step in providing all sorts of functionality with your game, like friends lists, leader boards, chat, and multiplayer.

Creating immersive gameplay with the Full Screen API

Something that prevents current games on the Web from feeling immersive is that they look like they’re just tiny boxes embedded into another website. Why do they feel like that? Well, because they are just tiny boxes embedded into other websites. The odd 5-minute puzzle game during your lunch hour might feel OK in a tiny box surrounded by browser UI and other distractions, but a first-person shooter or driving game certainly wouldn’t.

Fortunately, the Full Screen API has arrived to solve this problem. It allows you to make any DOM element fill the player’s entire screen, something normally only considered for videos. Using this in a game can make the difference between 5 minutes of relative fun and hours of immersive delight.

Like most of the JavaScript APIs, it’s pretty easy to implement full-screen functionality in your game. All you need to do is call the requestFullScreen method on the desired DOM element:

var elem = document.getElementById("myGame");
if (elem.requestFullScreen) {
    elem.requestFullScreen();
} else if (elem.mozRequestFullScreen) {
    elem.mozRequestFullScreen();
} else if (elem.webkitRequestFullScreen) {
    elem.webkitRequestFullScreen();
}

Taming mouse input with the Mouse Lock API

An issue related to input in games is that of misbehaving cursors, where the mouse is used to rotate a player around a fixed point, like moving the viewpoint in a 3D first-person shooter, or rotating the player in a top-down 2D game.

In both of these situations, the mouse cursor is visible at all times, which is generally annoying and ruins the experience. However, the most debilitating problem is that when the mouse cursor leaves the browser window all movement stops. This same behaviour occurs in full-screen mode when the mouse cursor hits the edge of the screen. It’s a horribly simple problem for players that completely ruins the experience.

The good news is that the Mouse Lock API has been created to solve this problem, and it just landed in experimental builds of Firefox Nightly. Its sole purpose is to tame the mouse by hiding the cursor and locking it in place so it doesn’t hit the edges of the screen. This means that instead of relying on x and y coordinate values for mouse position in related to the top-left corner of the browser, you instead rely on x and y distance values from the position that the mouse was locked to.

Using the Mouse Lock API is really just a case of calling the navigator.pointer.lock method. However this must be done in full screen mode to work properly (and remember to use the experimental build of Firefox linked previously).

The following example expands a <div> element to full screen and locks the mouse in place at the same time:

<script>
function fullAndLock() {
  var div = document.getElementById("div");

  document.addEventListener("mozfullscreenchange", function() {
    var pointer = navigator.pointer;

    if (document.mozFullScreen &&
        document.mozFullScreenElement === div &&
        !pointer.islocked()) {

      function onMouseLockSuccess() {
        console.log("Mouse successfully locked");
      }

      function onMouseLockError() {
        console.log("Error locking mouse");
      }

      pointer.lock(div, onMouseLockSuccess, onMouseLockError);
    }
  }, false);

  div.mozRequestFullScreen();
}
</script>
<button onclick="fullAndLock();">Mouse Lock</button>
<div id="div">Element to receive mouse lock</div>

Here is a quick video of the Mouse Lock API in action, with comparison to non-mouse lock game-play to see the improvement:

Providing a console-like experience with the Gamepad API

Another input-related improvement that is coming to the Web is that of the Gamepad API. No longer are the keyboard and mouse the only options available for your players to engage with your game. The Gamepad API now allows for all sorts of gamepads to be accessed via JavaScript. This even includes some of the console controllers like those on the xBox 360 and Playstation 3 (with third-party drivers)!

Like the Mouse Lock API, the Gamepad API has just landed in experimental builds of Firefox Nightly and it’s nice and simple to use. Coupled with the Full Screen API, gamepad support can really change the experience of your game from that of a game within a website to that of a desktop game or console.

To find out when a gamepad has been connected, you need only listen to the MozGamepadConnected event on the window object (remember to use the experimental build linked previously):

<div id="gamepads"></div>
<script>
function gamepadConnected(e) {
  var gamepads = document.getElementById("gamepads"),
    gamepadId = e.gamepad.id;

  gamepads.innerHTML += " Gamepad Connected (id=" + gamepadId + ")";
}

window.addEventListener("MozGamepadConnected", gamepadConnected, false);
</script>

Receiving updates about all the buttons and joysticks on a gamepad is also a case of listening for events, or you can manually poll the status of buttons and joysticks whenever you want. Check out the Gamepad API documentation and the input.js library for more information.

The video below shows the Gamepad API in action, controlling a player in the game Rawkets:

Adding real-time multiplayer game-play with WebSockets

If you’re thinking of creating a multiplayer game then before now you would either have put up with the latency involved in constant AJAX requests, or you would have moved to Flash. Neither option is ideal. What’s cool is that since last year this is no longer the case, WebSockets have now arrived to allow for real-time bi-directional communication between the browser and a server.

But why is bi-directional real-time communication important for games? Well, this means that you can now literally stream data to and from a player’s browser in real time. One obvious benefit to this is that it saves bandwidth by no longer requiring constant AJAX requests to check for new data. Instead the WebSocket connection is left open and data is instantly pushed to the player or server as soon as it is needed. This is perfect for fast-paced games that require updates every few milliseconds. On top of this, the bi-directional nature of WebSockets means that data can be instantly sent both from the server to the player and from the player to the server at the same time.

Using WebSockets is a case of connecting to the socket server by initialising the WebSocket object:

var mySocket = new WebSocket("http://www.example.com/socketserver",);

From there you can send data using the send method of the WebSocket object:

mySocket.send("Here's some text that the server is urgently awaiting!");

And you can receive data by listening for the onmessage event on the WebSocket object:

mySocket.onmessage = function(e) {
  console.log(e.data);
}

A full code example for game communication would be too much for this post but you should definitely check out the tutorial that that I made a couple months ago. In it I detail exactly how to create a real-time multiplayer game using Node.js and WebSockets.

Using games offline with local storage and the application cache

Creating games on the Web is all well and good, but what about if you want to play that game offline? Or, what if the player’s Internet connection drops out half way through an epic gaming session? Most open Web games today would at worst simply stop working as soon as an Internet connection fails, and at best they would stop sending data to your server and saving player data. When your player refreshes the page that the game is on, they’ll just see a blank page and all their hard work achieved while offline will have been lost. That probably won’t make your players very happy, and unhappy players are not ideal.

There are a few solutions available today that can help solve these issues. The first is the application cache, which allows you to use a cache manifest to declare particular assets (like HTML, CSS, images, and JavaScript) that you would like the browser to cache for offline use. Not only that, the browser uses the cached versions of the files when when online to speed up the loading process.

You can include a cache manifest within your game by using the manifest attribute of the <html> element:

<html manifest="example.appcache">
  <h1>Application Cache Example</h1>
</html>

Writing a cache manifest is straightforward and requires you to follow a simple format to declare the files that you want cached. For example, the manifest below looks for /example/bar online and falls back to the locally-cached example.html file if your player is offline or experiencing network issues:

CACHE MANIFEST
FALLBACK:
example/bar/ example.html

There is much more to cache manifest than this, so I advise you to read the documentation to discover it in detail.

Another technique you can use is to store a player’s game data locally and periodically sync it with the game server. Normally you wouldn’t be able to store enough data in the browser to achieve this (like with cookies) but with Local Storage and IndexedDB, you can now store many megabytes of data in a structured way.

You can also add functionality to your game so it is alerted when a player’s Internet connection goes offline. The navigator.onLine property allows you to use JavaScript to see if your player is currently online or not. You can also use the offline and online events to trigger automatic behaviour in your game when a change in connection occurs, like stopping all WebSockets communication and caching player data locally until the connection is back.

Creating native OS applications with WebRT

One of the more profound aspects of the Mozilla Labs Apps project is the integration of a Web run-time (WebRT). This allows players to install your game "natively" on their chosen operating system (Windows, Mac, and Android right now), with a launch icon just like standard OS applications.

WebRT also runs your game using an app-centric user agent (in contrast to browser-centric user agents like Firefox) and runs your game using a separate user profile and OS process to your player’s normal Firefox that they use for browsing.

The ability of WebRT to break away into another process and remove all the browser UI makes the experience for gaming that much sweeter. There’s something about having an icon in the dock on a Mac that launches your game in it’s own "native" window with no mention or feel that this is a browser.

As a developer this is slightly magical. It allows you to break free from a game being a glorified website, instead turning it into an application, an experience in its own right. Mark my words, this will be a turning point in the transition from 5-minute puzzle games on the Web to professional-grade games that have a console-like experience.

The great news is that enabling WebRT on your game is just a case of creating an app manifest and calling the navigator.mozApps.install method through JavaScript.

This is an example app manifest from the Rawkets game:

{
    "name":"Rawkets",
    "developer": {
        "name":"Rob Hawkes",
        "url":"http://rawkes.com"
    },
    "description":"Space shooter game.",
    "icons": {
        "16": "/style/img/icon-16.png",
        "48": "/style/img/icon-48.png",
        "128": "/style/img/icon-128.png"
    },
    "launch_path": "/index.html",
    "installs_allowed_from": ["*"]
}

As you can see it’s a simple JSON structure. You would then need to pass that manifest file in the call to the navigator.mozApps.install method:

function installCallback(result) {
  // great - display a message, or redirect to a launch page
}

function errorCallback(result) {
  // whoops - result.code and result.message have details
}

navigator.mozApps.install(
  "http://rawkets.dev:8000/manifest.webapp",
  installCallback,
  errorCallback
)

This is the most basic implementation possible and would result in a panel popping up in the player’s browser asking if they’d like to install your game and whether they’d like that installation to be a native app or not (like the screenshot above).

Making money from your passion with the Mozilla Labs Apps project

Finally, the last thing about the apps project that I want to cover is that of making money from your game. Let’s be honest, if you can’t make a living from something then you’re going to have a hard time keeping it up for a long period of time.

For the Mozilla app marketplace we are using PayPal as the payment provider. All you need do is set a price on the store and the rest will happen automatically as people start paying for your game — you’ll start receiving money in your PayPal account.

In the future you’ll be able to provide your game on your own website or another store and charge for it there also. This means you’ll be able to use your own payment provider.

Scratching the surface

These technologies are really just scratching the surface when it comes to creating games on the Web using open technologies. At Mozilla we’re working hard to bring you these APIs and services to help make the Web a better place for games. The year 2012 will be a game-changer, for sure (pun intended).

Keep an eye on this blog as we’ll be sure to post more updates and guides as our gaming technologies and the apps project mature.

In the meantime, here are a few of places to go for extra information on the Mozilla Labs Apps project and gaming at Mozilla:

• Mozilla Labs Apps project developer documentation
• Documentation on developing games with the apps project
• Blog post about the Gamepad and Mouse Lock APIs
• Wiki page about Mozilla’s Paladin team. These are the guys working on the Gamepad and Mouse Lock APIs, amongst other awesome things.

As explained in this blog post by Jared Wein of the Firefox team there are quite a few new features in Firefox when it comes to playing HTML5 video. As an Aurora user, I am most excited about the option to go full-screen, the ability to overlay video statistics and to save a snapshot of the current frame as a JPG. You can see me talking about and showing them in this short video:

Firefox has a few features up its sleeve when it comes to HTML5 video playback you might not be aware of:

• Firefox‘s seeking is now accurate to millisecondsmicroseconds, there is visual feedback when the video has stalled and clicking the whole video pauses and plays it
• Firefox Beta has specialised controls when you watch video on small devices and watching HTML5 video shows a pleasing background rather than a brutal grey
• Firefox Aurora has fullscreen, statistics overlay, saving of snapshots and controls appearing when the video ended
• Firefox Nightly has a full-screen button, fading video controls after 2 seconds of non-interaction, no loading throbber on audio, error reporting when a video could not be loaded on the video, loop attribute support, and resizing of videos larger than the browser window when you watch them directly

Planned features for Firefox are an overlay play button like YouTube when the video is not set to autoplay and turning off screensavers during fullscreen playback.

Check out Jared’s post for more information.

Thursday is here, and just like every week when that day comes, we at Mozilla want to share some good reading with you.

Continued…

A few days ago I was asked to deliver the first talk of the amazing Beyond Tellerand conference in Dusseldorf, Germany. The talk Breaking the barriers – moving browsers and the web forward introduced a lot of new ideas and technologies that are worked on my Mozilla and others to make the web of the future better.

Here is the video of the presentation with jump points and links to more information. If you want to see the slides of the talk, they are available here and there is also an audio recording on archive.org.

Breaking the barriers – moving browsers and the web forward from marc thiele on Vimeo.

Here’s what is covered in the talk:

1. Modern web technologies of HTML5 and friends that can be used right now (with 64 myself as a demo) [03:50 - 07:19]
   • Rich HTML semantics (HTML5)
   • Self-validating forms (HTML5)
   • Richer form controls with fallbacks (HTML5)
   • Canvas for painting in the browser (HTML5)
   • CSS gradients, multiple backgrounds, animation and transition
   • CSS 3D transforms
   • Local storage and offline storage
   • SVG for scalable and interactive graphics
   • RequestAnimationFrame for secure animation
   • History API
   • WebGL
2. Taking on challenges – we need you to show the world that web technology is good enough to do jobs that in the past were only possible with native or server-side code (with Joe Lambert’s image unshredder as the example) [07:20 - 08:04]
3. Breaking the browser mould – showing that the browser interfaces can be manipulated with HTML and JS (with browser menus, context menus and the Fullscreen API as examples) [08:05 - 10:54]
4. Developing with the web – developer tools in browsers and done in client side technologies (with Hackasaurus, Cloud 9 IDE, Firefox Scratchpad, Firefox Style Editor, Parse error display in view-source and Tilt as examples) [10:55 - 17:24]
5. Online identity and issues with current login systems (with BrowserID as a solution to a lot of the problems we have right now) [17:25 - 29:35]
6. Apps, the shortcomings and myths of native apps and the opportunity to build hybrid apps with web technologies (with Open Web Apps and Web Intents as examples) [29:36 - 37:34]
7. Moving web technologies into the mobile space (with Are we mobile yet? and Boot to Gecko as demos) [37:35 - 40:11]
8. How can you help? [40:12 - 42:33]