Introduction

Raphaël is a library originally written by Dmitry Baranovskiy and is now part of Sencha Labs.

The goal of this library is to simplify work with vector graphics on the Web. Raphaël relies on the SVG W3C Recommendation (which is well supported in all modern browsers) and falls back to the Micrsoft VML language in order to address legacy versions of Internet Explorer. It also tries to harmonize some working issues across SVG implementations such as the SVG Animations. As a consequence, Raphaël is a very nice wrapper to produce consistent kick-ass graphics all over the Web.

Basic usage

The library has very good documentation with many examples. Do not hesitate to use it extensively.

The following example will draw a simple red circle inside an HTML element with the id “myPaper”.

// the following example creates a drawing zone
// that is 100px wide by 100px high.
// This drawing zone is created at the top left corner
// of the #myPaper element (or its top right corner in
// dir="rtl" elements)
var paper = Raphael("myPaper", 100, 100); 
 
// The circle will have a radius of 40
// and its center will be at coordinate 50,50
var c = paper.circle(50, 50, 40); 
 
// The circle will be filled with red
// Note that the name of each element property
// follow the SVG recommendation
c.attr({
    fill: "#900"
});

Advanced usage

Despite the fact that Raphaël reduces the possibilities offered by SVG (mainly because of the VML fallback) it allows one to perform very advanced stuff:

• Advance Matrix transformation
• Advance event handler
• Cross browser animations
• Easy drag system
• Path intersection detection

Raphaël is also extensible through an extension system that allows you to build custom functions.

For example, here’s an extension to draw pie charts:

/**
 * Pie method
 *
 * cx: x position of the rotating center of the pie
 * cy: y position of the rotating center of the pie
 * r : radius of the pie 
 * a1: angle expressed in degrees where the pie start
 * a2: angle expressed in degrees where the pie end
 */
Raphael.fn.pie = function (cx, cy, r, a1, a2) {
    var d,
        flag = (a2 - a1) > 180; 
 
    a1 = (a1 % 360) * Math.PI / 180;
    a2 = (a2 % 360) * Math.PI / 180; 
 
    d = [
        // Setting the rotating axe of the pie
        "M", cx, cy,
 
        // Go to the start of the curve
        "l", r * Math.cos(a1), r * Math.sin(a1),
 
        // Drawing the curve to its end
        "A", r, r, "0", +flag, "1",
        cx + r * Math.cos(a2), cy + r * Math.sin(a2),
 
        // Closing the path
        "z"
    ]; 
 
    return this.path(d.join(' '));
};

Note: In the example above, you have to be familiar with the SVG path syntax (Raphaël will convert it to the VML syntax under the hood), but once it’s done you can reuse it as any other Raphaël primitive. Look at this extension working to draw a color wheel on jsFiddle.

Limits and precaution

If you are not familiar with SVG and/or want to support legacy MS Internet Explorer browsers, this tool is made for you. However, it’s a JavaScript library, which means that you have to know JavaScript to use it. You cannot use SVG and ask Raphaël to parse it and interpret it (to do that, it exists other libraries).

In terms of browser support, Raphaël gives you a large base. Raphaël currently supports Firefox 3.0+, Safari 3.0+, Chrome 5.0+, Opera 9.5+ and Internet Explorer 6.0+.

In fact, the only browser that can not take advantage of Raphaël is the native browser for Android 1.x and 2.x (and obviously many feature phone browsers). This is due to the fact that those browsers do not support any vector language. Android starts (partially) supporting SVG with Android 3.0 so take care if you want to work with all mobile devices.

Conclusion

Raphaël was the first library to allow web designers and web developers to use SVG in the wild. If you want to write some nice applications without the need of the full SVG DOM API or if you have to support legacy browsers, this library will give you some power.

In conclusion, here are some cool usages of Raphaël:

• http://vlog.it/
• http://type.method.ac/
• http://shape.method.ac/
• http://www.nissanusa.com/leaf-electric-car/index
• http://ilovedemocracy.arte.tv/fr/

One of the best things about HTML is that it’s never “done”.  HTML has been with us longer than most of the development technologies that we consider commonplace. (.NET, ASP, Java, PHP, etc.)

The latest incarnation of HTML, HTML5 has been the source of a great deal of buzz in the software and information industries. When we say “HTML5″, we’re implicitly referring to the “stack” of  HTML/CSS/JavaScript.

At Mozilla we often refer to this collectively as the “Web Run-Time” or WebRT for short. Mozilla’s apps initiative, including the Web Runtime is documented here.

Skeptics like to say “HTML5 is not ready”. This week I saw an article declaring HTML5 won’t be “ready” for another 10 years. To which I ask “ready for what?” Of course there are many APIs that are still under development, but for many scenarios HTML5 is ready now. For many other scenarios its ready for development now and will be ready for general public use in the near future.

Recently the Mozilla Apps Native Install Experience was introduced to the Firefox Nightly Channel. (Read here for more information about the Firefox release channels.)

This functionality lets us install an HTML5 application with a native launching experience on Windows or Mac (Linux and Android coming).

One great way to do this is to simply list your app in the Mozilla Marketplace. The Marketplace will be open to the general public soon and developers can submit their app now at the Marketplace Ecosystem Portal. All you need besides an app to submit is a set of BrowserID credentials.

An HTML5 App that targets the Mozilla Web Runtime includes a manifest file.

The manifest is simply a JSON file that declares certain data about the application.

Here is the manifest file from a sample app. You can read more about the Mozilla App Manifest here.

    {  
      "version": "1.0",  
      "name": "KO Round Timer",  
      "description": "A Workout Timer for Fighting Athletes!",  
      "icons": {   
        "128": "/images/icon-128.png"  
      },    
      "developer": {  
        "name": "Joe Stagner",  
        "url": "http://koscience.com"  
      },  
      "installs_allowed_from": [  
        "http://timer.koscience.com", 
	"https://marketplace.mozilla.org"   
      ],    
      "default_locale": "en"  
    }

JSON does not need to be formatted with CRLFs. The above JSON is only formatted to simplify display.

Note line #12 above which specifies where the app can be installed from.

The Mozilla Web Runtime includes an apps object (winbow.navigator.mozApps) The mozApps object (currently implemented in Firefox Nightly on Windows and Mac) has a method to install an application. We’ll look at code that uses that API in a minute.

If you want your app to install from the Mozilla Marketplace you don’t need to write any install code. When you list your app in the marketplace, the marketplace creates a listing page for your app and that page includes an install button.

The generated code that is invoked when the Install button is clicked tells the Runtime to install the app. The Runtime then fetches the manifest for the app and, among other things, checks to see it the app allows installation from whatever domain is requesting the install.

As you can see in the manifest listing above, line 14 specifies that the app may be installed from “https://marketplace.mozilla.org”.

But you might want to let users install your application from other domains, for example your own web site.

You can see line 13 in our sample manifest, listed above, that “http://timer.koscience.com” is also specified as a valid “install from” location. I can specify as many domains as I like to be authorized to install the application from and wildcards are supported.

If we want to install the app from our own web site however, we need to implement the install logic ourselves.

We could create a page similar to the app listing page on the Mozilla Marketplace, or could make the app “self installing” meaning that we could implement installation logic in the app itself.

Take, for example, the Workout Timer app shown below.

Notice the row of navigation buttons at the bottom of the timer.

The last one to the right says “Install Me”.

The install button should only appear if the app is running in an environment that supports the mozApps runtime. Since this app (K.O. Timer) is an HTML5 app it can run in any HTML5 compliant browser but will only be “installable” if it is running in a browser / runtime with mozApps support.

We also don’t want the install button to appear if the app is already installed.

Here is a JavaScript method to test both runtime support and install state.

If runtime support is present and the app is not install then an install button is displayed.

In some scenarios you might choose to forgo the display of an optional install button and simply start the installer when the app is not already installed.

(This code is using jQuery)

function TestAppInstalled() {
    if ((!navigator.mozApps) || (!navigator.mozApps.getSelf)) {
        /*-----------------------------------------------------------+
        || Test to see if the Mozilla Apps Web Runtime is supported
        || HACK: Testing for either mozApps OR mozApps.getSelf is a 
        || hack. 
        || This is needed because some pre-beta versions of Firefox 
        || have the object present but nit fully implemented.
        || TODO: Update when Firefox Desktop & Mobile are complete.
        ------------------------------------------------------------*/
        return;
    }
 
    var MyAppSelf = navigator.mozApps.getSelf();
    MyAppSelf.onsuccess = function() {
        if (! this.result) {
            // Application is not "installed"
            $('#InstallButton').show();
        }
        else {
             // This "MozApp" is already installed.
        }
        return;
    }
    MyAppSelf.onerror = function() {
        alert('Error checking installation status: ' + 
               this.error.message);
        return;
    }
}

When the user clicks on the install button the following code is called.

$('#InstallButton').click(function() {
    var installation = navigator.mozApps.install(
                "http://timer.koscience.com/kotimer.webapp");
    installation.onsuccess = function() {
        $('#InstallButton').hide();
        alert("K.O. Timer has been successfully installed.....");
    }
    installation.onerror = function() {
        alert("APP: The installation FAILED : " + this.error.name);
    }
});

So when the user navigates to the K.O. Timer app (timer.koscience.com) in a browser that supports mozApps (currently Firefox Nightly) and the user clicks on the “Install Me” button the mozApps runtime starts the installer.

After the user clicks “install” button in the dialog pictured above, the installer is called and, when completed, the user has a native launching experience.

On Windows you get a desktop shortcut.

As well as a Start Menu item.

And, of course the app is now in the user’s Mozilla MyApps collection.

It’s important to remember that, while these launchers have been created on the user’s system the application itself still exists in the cloud. A developer can choose to add “off line” functionality to their application by other HTML5 features like AppCache, LocalStorage or IndexedDB.

The ability to provide native launchers for HTML5 apps, coupled with the huge HTML5 apps distribution mechanism that will be available when the Mozilla Marketplace become available to the general public (in the near future), creates great opportunity for developers building standards based apps.

If you have no idea what hack day in MDN means, check out Tristan Nitot’s introductory post.

There are still tickets available, so go to http://mdn-hackday-london.eventbrite.com/ and sign up if you haven’t yet.

There’ll be food (well, Pizza, we thought Fondue would be too much of a mess) and drink (the non-fermented and fermented kind, we don’t discriminate), lots of experts from Mozilla to pester about your wishes for our products and to learn all about what we are doing in London, a few Boot to Gecko phones to play with and quite a few talks to give you inspiration to hack:

Schedule (subject to change slightly but you get the idea of who is speaking):

8:30 Registration & Light Breakfast
9:00 Welcome Remarks Christian Heilmann
9:15 Christian Heilmann – The New Web Challenge
9:45 Rob Hawkes – B2G
10:15 Chloe Varelidi – Catch Them Young – Meet the Web Arcade
10:45 Brad Lassey – Fennec Goes Native
11:15 Break
11:30 Heather Arthur – Firefox DevTools
12:00 Jean Yves Perrier – BrowserID
12:30 Rob Hawkes – Games
1:00 Paul Lewis – WebGL Live Demos
1:30 Lunch (Lightening Talk/Discussion Group Sign Up)
2:30 Hacking
5:15 Presentations and Lightning Talks
5:30 Refreshments

The hashtag to use is #mdnhackday, the wireless is open, the Fox is out there, let’s do this!

Although Snappy first contributed fixes to Firefox 11, Snappy’s most noticeable contributions to date are landing with Firefox 13. Currently in beta, this release includes a number of responsiveness related fixes, most notably tabs-on-demand, cycle collector improvements, and start-up optimization.

Tabs -on-Demand

Tabs-on-demand is a feature that reduces start-up time for Firefox windows with many tabs. In Firefox 12, all tabs are loaded on start-up. For windows with many tabs this may cause a delay before you can interact with Firefox as each tab must load its content. In Firefox 13, only the active tab will load. Loading of background tabs is deferred until a tab is selected. This results in Firefox starting faster as tabs-on-demand reduces processing requirements, network usage, and memory consumption.

Cycle Collector

As you interact with the browser and Web content, memory is allocated as needed. The Firefox cycle collector works to automatically free some of this memory when it is no longer needed. This action reduces Firefox’s memory usage. In Firefox 13, the cycle collector is more efficient, spending less time examining memory that is still in use, which results in less pauses as you use Firefox.

Start-up

Firefox start-up time is visible to all users. Our investigation into start-up has identified a number of unoptimized routines in the code that executes before what we call “first paint”. “First paint” signifies when the Firefox user interface is first visible on your screen. In Firefox 13 we have optimized file calls, audio sessions, drag and drop, and overall IO, just to name a few. We are continuing to profile the Firefox start-up sequence to identify further optimizations that can be made in future releases.

There are numerous other Snappy fixes in Firefox 13 including significant improvements to IO contention, font enumeration, and livemark overhead. All of these fixes contribute to a more responsive experience. We are already working on further responsiveness fixes for future Firefox releases. You can expect to see Snappy improvements in upcoming releases in areas such as memory usage, shutdown time, network cache and connections, menus, and graphics.

The original idea behind DOM Mutation Events is still appealing, however, and so in September 2011 a group of Google and Mozilla engineers announced a new proposal that would offer similar functionality with improved performance: DOM MutationObserver. This new DOM Api is available in Firefox and Webkit nightly builds, as well as Chrome 18.

At it’s simplest, a MutationObserver implementation looks like this:

// select the target node
var target = document.querySelector('#some-id');
 
// create an observer instance
var observer = new MutationObserver(function(mutations) {
    mutations.forEach(function(mutation) {
        console.log(mutation.type);
    });    
});
 
// configuration of the observer:
var config = { attributes: true, childList: true, characterData: 	true }
 
// pass in the target node, as well as the observer options
observer.observe(target, config);
 
// later, you can stop observing
observer.disconnect();

The key advantage to this new specification over the deprecated DOM Mutation Events spec is one of efficiency. If you are observing a node for changes, your callback will not be fired until the DOM has finished changing. When the callback is triggered, it is supplied a list of the changes to the DOM, which you can then loop through and choose to react to.

This also means that any code you write will need to process the observer results in order to react to the changes you are looking for. Here is a compact example of an observer that listens for changes in an editable ordered list:

<!DOCTYPE html>
<ol contenteditable oninput="">
  <li>Press enter</li>
</ol>
<script>
  var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
  var list = document.querySelector('ol');
 
  var observer = new MutationObserver(function(mutations) {  
    mutations.forEach(function(mutation) {
      if (mutation.type === 'childList') {
        var list_values = [].slice.call(list.children)
            .map( function(node) { return node.innerHTML; })
            .filter( function(s) {
              if (s === '<br>') {
                return false;
              }
              else {
                return true;
              }
        });
        console.log(list_values);
      }
    });
  });
 
  observer.observe(list, {
  	attributes: true, 
  	childList: true, 
  	characterData: true
  });
</script>

If you want to see this code running, I’ve put it up on jsbin here:

http://jsbin.com/ivamoh/53/edit

If you play with the live example, you’ll notice some quirks in behaviour, in particular that the callback is triggered when you press enter in each li, in particular when the user action results in a node being added or removed from the DOM. This is an important distinction to be made from other techniques such as binding events to key presses or more common events like ‘click’. MutationObservers work differently from these techniques because they are triggered by changes in the DOM itself, not by events generated either via JS or user interaction.

So what are these good for?

I don’t expect most JS hackers are going to run out right now and start adding mutation observers to their code. Probably the biggest audience for this new api are the people that write JS frameworks, mainly to solve problems and create interactions they could not have done previously, or at least not with reasonable performance. Another use case would be situations where you are using frameworks that manipulate the DOM and need to react to these modifications efficiently ( and without setTimeout hacks! ).

Another common use of the Dom Mutation Events api is in browser extensions, and in the next week or so I’m going to publish a follow-up post on how MutationObservers are particularly useful when interacting with web content in a Firefox Add-on.

Resources

• Original Proposal
• W3C Spec
• Screencast by Rafael Weinstein
• Mutation Summary, a JS library that simplifies MutationObserver usage.

At the end of this blog post, you also have all the Developer Engagement team members and what they work on. If you are interested in discussing more, contributing or taking part of our work, don’t hesitate to contact us or follow us on Twitter!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

• WebGL Transforms
• Processing XHR2 file uploads in PHP
• Promises and timing in JS: “Write logic, not mechanics”
• How Gliffy is managing the risk of rewriting their product in HTML5
• CamanJS – Image Manipulation in Javascript
• Hiding content untangled: Hiding vs. moving out of the visible viewport. (We don’t always do this right on Mozilla sites, but we’re working on making them better.)
• Great video that shows how to get started with Canvas really quickly: CreativeJS for non-coders on Vimeo
• ChromaPad
• How to revive the Web: 10 Hypotheses (PDF)

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

Outside the usual categories of docs, Tom Lowenthal created a page of privacy policy guidelines, with help from Jishnu Menon, along with a privacy policy template that you can fork on Github. If you missed the earlier Hacks post about privacy guidelines, check it out.

Help needed

Fbender added a note to the Talk page for JavaScript Functions and function scope that “conditionally defining a function throws an error in at least ES5 strict, possibly non-strict (at least soon), too, see Bug 609832 and Bug 585536. The section Conditionally defining a function should be updated to reflect those changes.” Want to make that change? Go for it!

Web standards docs

• Airportyh added compatibility info to event.defaultPrevented.
• Will Bamberg updated Browser detection using the user agent.
• Ethertank created or updated translations on a bunch of Japanese pages.
• Fusionchess continued to be prolific:
  • Added an example of using a Blob object to Using XMLHttpRequest.
  • Added an example of the constructor to Blob.
  • Updated and expanded Object defineProperty.
  • Modified the example for using ‘apply’ to chain constructors in Function apply.
  • Created a page for JXON.
  • Made JSON consistent with other technology landing pages.
  • Added a code example and cross-references to How to create a DOM tree.
• Fusionchess and Hitautodestruct both expanded the information on ternary evaluation Conditional operator.
• Bertrand Malet added code examples to element.onmouseout and element.onmouseover.
• Masayuki updated KeyboardEvent and added ‘getModifierState’ to MouseEvent.
• Timoté Neullas translated Adding 2D content to a WebGL context into French.
• OoOoOoOo created border-image-slice.
• Jeremie Patonnier created pages for the SVG attributes color and color-profile.
• Thierry Régagnon added browser compatibility info to transition-duration and translated several other pages into French.
• Eric Shepherd added a list of status codes to the WebSockets CloseEvent reference page.
• Masataka Yakura updated compatibility and added external references to console.dir, console.log, console.error, console.info, console.warn, Blob and BlobBuilder.
• Ziyunfei translated or updated translations on a bunch of Chinese pages. Really, really a lot of Chinese pages.

Mozilla technology docs

• Malina Das created a page on Emulator integrated tests for Marionette and updated Marionette Python tests.
• Greg Koberger added info on serving manifests from Apache to Apps Manifest
• Nickolay Ponomarev added a section on instructions supported in bootstrapped extensions to Chrome registration, updated and corrected Bootstrapped extensions, and updated nsIComponentManager.
• Eric Shepherd created a page to document Using the source editor in Firefox developer tools.
• Till Schneidereit created Setting up CDT to work on SpiderMonkey.

Two weeks ago, the Firefox team got together for a work week in Toronto. It was amazing. Walking through a room with that many excellent people doing excellent things was inspiringhumblingunbelievable and the hits kept on rolling.

The combined mobile and graphics teams cut the beta blocker list for Fennec Native in half. The desktop team banged together a working prototype of sign in to the browser. The firefox tech leads worked with product and project management to nail down the kilimanjaro bug list for desktop. Madhava gave a great talk about the future of Firefox UX. I would have scored it as a strong success based on those outcomes alone.

And then this happened:

Hacking

• Scratchpad backending to github gists
• Jetpacks in scratchpad
• Task-specific icons in Windows 7 jumplists
• Finalized interactions and designs for the new downloads manager
• Sync meet-up and discussion to evaluate how to move forward with a smaller core, by moving data handling to components and allowing the Sync team to concentrate on the real Sync functionality
• Session Store meet-up and discussion on how to move forward with “Speedy Session Restore” as well as SS2 (rewriting SS).
• Initial explorations of a Fennec reading mode (post-1.0)
• Implemented Windows 8 appbar
• Roll your own one-off, bespoke debuggers in the scratchpad.
• Responsive Design tool for web developers

Lightning Talks

• Honza made Firebug’s HTTP Monitor a standalone component, and it can now remote-monitor fennec, too
• Gavin gave a great talk about code review
• Tim Abraldes demoed the Web App runtime
• Margaret walked us through Hacking Fennec
• Brian Bondy updated the status of our Windows 8 work
• Felipe found and fixed memory leaks with about:cc
• Dietrich walked through the state of the browser components team
• David Dahl went meta, and talked about giving Firefox talks in our community

I know I’ve missed things. I know some of it is still being written up. In fact, I’m not even the first to write a round up post. Here’s Finkle doing the same, and dcamp, and cwiiis.

FX-Team is big enough these days that it’s quite an undertaking to get us all together in one place. But man, it’s phenomenal when we do.

Articles

• Financial Times passes 2m users for its HTML5 web app
• Coding the future: HTML5 takes the internet by storm
• Utilize JavaScript messaging with postal.js
• Open Source Metro style theme for jQuery Mobile
• JavaScript Style Guides And Beautifiers
• Spine.js vs Backbone.js
• HTML5 – You’ll never believe how LinkedIn built its new iPad app

Resources

• 10 useful libraries for JavaScript developers
• HTML5.org – The Web platform: Browser technologies index
• The Jasmine Unit testing framework for JavaScript applications
• Screenful.js – Simple wrapper for cross-browser usage of the JavaScript Fullscreen API
• Fixie.js – JavaScript tool to automatically add filler content to HTML documents
• skrollr – A JavaScript library to animate any CSS property of any element based on the horizontal scrollbar position
• Cookies – Client-Side Cookie Manipulation API
• JSCheck – a testing tool for JavaScript

Bonus Link

• DevCon5 Video Presentation – Node.js in Context with Jason Hoffman of Joyent

If you find a link that you think should be included, please feel free to forward it to JStagner at Mozilla.com

This month, we are excited to see what you can do with Websockets. Websockets allow you to send messages to a server and receive event-driven responses in real time, without server polling. But this is about more than just sending messages. Websockets have been used in BrowserQuest, Rawkets, and many other highly interactive applications.

Setting up a Websockets demo is more involved than setting up a static demo, but we know you can do it. As long as you keep these three simple rules in mind, everything should work flawlessly.

1. To use Websockets, you need a server to communicate with. Thankfully, free services like Heroku and Nodejitsu provide just that.
2. You do not need to use Heroku or Nodejitsu. If you use a different server, however, you must ensure that it has a signed SSL certificate.
3. When building your demo, be sure to use the wss:// prefix (not the ws:// prefix) to specify the address of your server.

If you have any questions about setup, please let us know in the comments. We will work with you to resolve any issues you encounter. Otherwise, good luck and have fun!

Want to get a head start on a future Derby? We are also accepting entries related to the WebGL (June Derby) and demos that push the limits of the web without using JavaScript (July Derby).

Firefox release channels

Basically, we have four different Firefox release channels:

Firefox Release

The official release of Firefox.

Firefox Beta

Testing the next version of Firefox befire it becomes the official release.

Firefox Aurora

For web/platform developers and early adopters.

Firefox Nightly

Nightly releases that contains experimental features. (covered regularly on Twitter from @firefoxnightly)

Firefox release timeline

Firefox is released on a six week schedule, meaning that every sixth week there will be new versions of Firefox Release, Firefox Beta and Firefox Aurora. Nightly is, naturally, released every night.

Running multiple versions of Firefox at the same time

There are many different ways of running multiple versions of Firefox at the same time. What it all comes down to is setting up different profiles that you have per each web browser instance. The easiest way is most likely to use the Profile Manager, as described on MDN.

If you are on Mac OS X, it’s easy to use the automated version of setting up multiple profiles of Firefox.

Another option, in plain code and as outlined in Multiple Firefox Instances, is to just launch the Profile manager directly:

# On Windows click Start > Run then:
"C:\Program Files\Mozilla Firefox\firefox.exe" -no-remote -ProfileManager
 
# Mac OS X and Linux, in Terminal
firefox -ProfileManager
 
# Depending on system/setup, you might need to do this from the directory
./firefox -ProfileManager

Testing Firefox Aurora

The version of Firefox that is the best version to test for web developers is Firefox Aurora. It is in a stable enough condition to use, but also has features at their latest stage before they become approved. Therefore, your chance to affect implementations, find bugs, improve features is when it has become Firefox Aurora – likewise, it gives us a better chance to ensure that when Firefox is officially released, all the things are in place in the best possible manner.

Therefore, please take the time to test out Firefox Aurora and new features, so we can together help Firefox and the web better!

Many Thanks Yous, One Mozilla

It was a whirlwind week and a half for the crew of the Mozilla MDN Hack Day Tour in Latin America. Over the course of 10 days we visited four cities in four countries in the Conosur, the southern part of South America. We met hundreds of developers in Buenos Aires, Argentina; Montevideo, Uruguay; Sao Paulo, Brazil; and Santiago, Chile. Thanks to everyone who took the time to listen, to talk with us, and make us feel welcome.

Our message was well-received: The Web is the platform and it’s built from open technologies. On this trip, we were eager to introduce some of the new projects Mozilla is working on now to keep the Web open as more of the world goes mobile. As a non-profit committed to promoting openness, innovation and opportunity on the Web, Mozilla works best with inputs and participation from communities everywhere.

In South America, we were a small team, carrying passports from Argentina, Canada, Sweden, Venezuela and the U.S. We spoke in a mix of Spanish and English. Personally I wish more of us had spoken Spanish, but because of my own language limitations, I was extra happy to listen to Spanish-speaking presenters at each of our events.

We talked about HTML5 & friends and new Javascript APIs. We introduced exciting new Mozilla open source projects like Boot-to-Gecko (B2G), our open web phone project that’s just getting started; the soon-to-be-launched Mozilla Marketplace for HTML 5 apps (presented by Mozilla Labs’ Shane Caraveo), and Mozilla Persona, a new identity system for the Web (presented in Spanish by Dan Mills).

In Argentina and Uruguay, Telefonica’s Andres Leonardo Martinez Ortiz introduced BlueVia, the developer program and platform from Telefonica, Mozilla partner and MDN Hack Day sponsor. In Buenos Aires, Kevin Dangoor spoke about the developer tools Mozilla is building and Buenos Aires-based add-ons developer and evangelist Hernan Colmeiro spoke about the beauty of add-ons. In Santiago, Chile, Hernan wowed developers with a Boot-to-Gecko demo.

There were dozens and dozens of individuals who helped make our tour a success, including Mozillians I work with every day and people I’d never met till we arrived in their country. The big risk in writing long thank-yous is that I will unintentionally to forget to mention someone essential, so please accept my apology in advance and don’t hesitate to use the comments.

Buenos Aires

We came to Buenos Aires for MozCamp LATAM, Mozilla’s first community gathering held in Latin America, co-hosted by the amazing, multi-national Mozilla Hispano community and their Portuguese-speaking neighbors from Mozilla Brazil.

On the Friday before MozCamp we organized a day-long Hack Day for developers from Buenos Aires. Over 150 developers attended a morning of talks and demos, followed by an afternoon of project hacking. After lunch, a lively group gathered around Add-ons developer Jorge Villalobos, while other attendees were riveted by Philikon’s demo of the Boot-2-Gecko phone.

MDN Hack Day would not have succeeded without the outreach, organizational support and hospitality of Felipe Lerena, Guillermo Movia, and Santiago Hollman of the Moz Hispano community. And I’ll add a special shout-out to the Mozcamp LATAM planning committee: Mary Colvig, Chris Hofmann, Santiago Hollmann, Gloria Meneses, Ruben Martin, Reuben Morais, Guillermo Movia, and the unflappable Katherine Naszradi. This couldn’t have happened without your support!

Montevideo

The crew left Buenos Aires on a sunny Monday afternoon, and crossed the Rio de la Plata by Buquebus ferry, arriving in Montevideo at nightfall, after a choppy 3-hour crossing.

The next morning I met up with old friend and colleague Evan Henshaw Plath, and new friends Diego Algorta, Elena Vilar and the Cubox Labs team who’d been helping us organize, promote and host MDN Hack Day in Montevideo. They work together in a classic 1920s home converted to a co-working space in a leafy residential neighborhood. I met our evening’s speakers, along with Frenchman Jean-Paul Massonnier, an awesome designer, who’d created a poster that was pure Mozilla. I drank delicious coffee and chatted with developers in the kitchen overlooking a garden where coders kicked a football around in the sunshine.

We headed over to Cafe La Diaria. La Diaria is a subscription-based independent newspaper that is now the 2nd most widely read paper in Uruguay. It is run cooperatively and distributed by employees, with a commitment to the highest journalistic standards. Cafe La Diaria is a venue and community space in the old downtown of the city. Here we met our hosts Damian and Antonieta, who cooked up delicious pizza at the break. Cubox’s Nicolas Barrera gave an entertaining and enlightening talk about responsive design, and Fernando Briano, Cuboxer and noted tech blogger served up a presentation on the web as a tool for Social Change.

In addition, there were two lightning talks: On his last night in Montevideo before moving to Berlin, MDN demo contributor and Developer Derby winner Alvaro Mourino (aka Tuxie) stopped by to talk about our Dev Derby and encourage people to participate. Dario Clavijo, a tech blogger and IT professional in Montevideo, spoke passionately about the importance of free and open software. It was his first ever lightning talk and we were honored to hear from him!

Sao Paulo

Robert Nyman, El Sueco, made the trip to Brazil by himself, since the rest of us yanquis were lacking visas. Here’s his report:

“The next leg of the tour, helpfully organized by local company Caelum, [was] a Mozilla one-man show from me giving two talks in Sao Paulo:

• HTML5, the Open Web and what it means to you
• JavaScript APIs – The web is the platform

In addition to that, local developer Gabriel Oliveira spoke about CSS3, and from what I could understand, he showed some really interesting things!

There were about 40+ attendees this very rainy night in Sao Paulo, and while there weren’t many people, I was really happy to see the nods of approval in the audience during my talk, when I expressed Mozilla’s values and approach to the web and moving forward. After my presentations, we stood around for a long time discussing the web, -webkit prefixes, H.264 support and more. People seemed to be understanding and pragmatic, and I believe there were some really talented people there.

Additionally, I got to spend some time being guided around by local community members Fábio Magnoni and Clauber Stipkovic, who I got to know in person at MozCamp in Buenos Aires, and had interesting discussions!”

Santiago, Chile

Our final Hack Day of the LATAM tour took place in Santiago, Chile on an overcast Saturday evening. We met in a comfortable classroom at the University of Chile’s Escuela de Economía y Negocios. Jano Gonzalez, a Ruby blogger and all around nice guy made the arrangements. His friends Paulina and Rodrigo took some of the team on a tour of the city.

More than 50 attendees came out to hear from us. Pizza Hut (!) delivered pizza during the break. Hernan Colmeiro came out from Buenos Aires to introduce Add-ons and to demo Boot-to-Gecko. And Jonathan Gonzalez, no relation to Jano, introduced the Monkey Project, a fast and scalable web server for Linux.

We had a strong showing of lightning talks: including presentations delivered in English, with slides in Spanish; presentations in Spanish, with slides in English; a compelling pitch by Ricardo about why you should overcome your shyness and get up at events to give talks about the stuff you know; a hilarious parody of a framework that was probably NSFW, but I didn’t understand enough of the Chilean slang so I can’t be sure; and an introduction to Poderopedia, a database that aims to map the relationships between political and financial power in Chile. We also met some entrepreneurs from the Startup Chile accelerator, and on Monday a couple of us had a chance to visit their lively space.

In conclusion

Huge thanks to the rest of the team – everyone was upbeat, professional, collaborative, and more fun than a barrel of monkeys: Shane Caraveo, Hernan Colmeiro, Dan Mills, Robert Nyman, and a special shout-out to Shezmeen Prasad, event organizer extraordinaire, who invited me along. Props also to Jeff Griffiths, who put it all together behind the scenes, from somewhere in Canuckistan. Gracias!

Photo credits: Prima Limon, thunder, and freshelectrons.

Update 2012-05-08: Thanks to last-minute magic by Mozilla IT, MDN won’t be completely unavailable after all. However, it will be running on a single virtual machine rather than three physical servers, so expect worse than usual performance during the time frame described below.

Mozilla Developer Network will be down for maintenance and completely unavailable for approximate eight hours on Tuesday, May 8th, 2012, starting at 15:00 UTC (Tue 17:00 CET, Tue 11:00 US-EDT, Tue 8:00 US-PDT). It should be back online by 00:00 UTC on Wednesday May 9th (Wed 02:00 CET, Tue 20:00 US-EDT, Tue 17:00 US-PDT).

During this time, the site will not be available for viewing or editing, so please make sure to save all your edits and be prepared in advance — maybe go outside and get some fresh air — MDN will be back before you know it.

Meanwhile, here are some alternative resources:

Open Web standards:

• DocHub mirrors content from MDN and other sources
• Dev.Opera has lots of Web technology articles
• W3C Web Design and Applications is a landing page for Web standards
• Safari Developer Library has many articles on Web development

Mozilla stuff:

• Mozilla wiki has all kinds of information related to the Mozilla project

Ramping up developers to submit and publish their apps to the Mozilla Marketplace we just released a few simple to understand Privacy policy guidelines complete with an HTML/CSS/RSS Privacy Policy Template on GitHub.

Whilst the guidelines are not a substitute for a real lawyer and don’t provide legal advice they have some very simple and powerful tips to get you going:

• Design your app or add-on so that what you actually do with user data is what users think you are doing with it.
• Try to give the user as much control over their data as you can, such as giving them the choice to opt-in to or opt-out of data collection whenever possible.
• Try to limit your data collection and use to only the data that you need.
• Design your app and service to protect the security of your user’s data in its collection, storage, and use.
• Respond to user questions and concerns about your privacy practices.
• Avoid ‘secret’ updates.
• Make your use of social features transparent, so that users are aware of when they’re sharing data socially.
• Give people a way to turn off automatic sharing or make more granular choices about sharing data.
• Obtain consent from users when necessary, especially for location and other sensitive information.
• Put a link to your privacy policy and, if you have them, your “terms of use” somewhere in your app.

Avoid confusion and problems in the future by getting the basics right – and that very much includes privacy concerns in your app.

At the end of this blog post, you also have all the Developer Engagement team members and what they work on. If you are interested in discussing more, contributing or taking part of our work, don’t hesitate to contact us or follow us on Twitter!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

• lake.js – Takes an img element and inserts a canvas element displaying the image and its flipped reflection directly after the img element
• Great rant on when to take your legacy code out back with a shotgun
• WebSockets: A Guide – Build New Games
• The Instagram Architecture Facebook Bought for a Cool Billion Dollars
• Don’t docwrite scripts
• Multiple Firefox Instances
• The three “bad” parts in JS aren’t so bad, just mind-bending and worth reviewing occasionally
• Augmented Paper
• Light Table – a new IDE concept

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

What is MDN?

Please, don’t laugh, you have no idea how many times I have heard this.

To get straight to the point, MDN is the Mozilla Developer Network. It’s a web site centralizing almost all the documentation about Mozilla products. Basically this site hosts three kind of resources:

• Articles and links to external resources to learn how to use web technologies
• Demos of cutting edge Web technologies available in modern Web browsers (Those demos come from the monthly Dev Derby contest organized by John Karahalis)
• Reference documentation (API, elements, attributes, properties) for Mozilla technologies and more important, reference documentation for all open Web technologies (HTML, CSS, JavaScript, SVG, WebGL, etc.)

The last part, the open Web documentation, is the most important (in terms of volume as well as quality) and the one where Mozilla currently puts its biggest effort. One thing to mention is the fact that this documentation is browser agnostic, with compatibility tables and implementation notes for all browsers, not just Firefox.

Even if this documentation can be considered as one of the best currently available on the Web, it’s far from complete, and you are more than welcome to help with filling the gaps ;)

Is it difficult to contribute?

Not at all, on the contrary, it’s amazingly simple. I even think it is the easiest way to contribute to Mozilla (there is no need to deal with Bugzilla :-P)

Actually, to contribute to MDN, you need two things:

• The will to contribute
• A user account on MDN

And that’s all.

The hardest things to do is to find the “Sign in” button in the upper right corner of the site, stuck between the search field and the ugly white Mozilla tab‚ — yeah, yeah, yeah not really the best place. Once you click it, you are prompted for an e-mail address and a password (MDN uses Mozilla Persona/BrowserID). After that, on the next page, you just have to provide a “user name” to identify your contributions on MDN and voilà, you are ready to contribute.

For its part, contributing is also really simple. Basically, MDN is 80% a wiki. So, on each page of the wiki, you’ll find an “Edit” button (in the upper right corner). Click it to load the page content into a WYSIWYG editor (don’t worry, if you want to be hardcore, you can switch to raw HTML editing). Make all the changes you want and save them (by clicking on the “Save” button on the upper left corner). Congratulations, you’ve made your first contribution to MDN and Mozilla: no stupid publication process, no delay, no review (of course, you can ask for it, but it’s not required) — too easy :)

What can I do, where do I start?

The short answer is “whatever and wherever you want”. Unfortunately, experience has shown me that it’s not the answer expected by newcomers.

Basically, you can do two things on MDN:

• Submit demos to the Dev Derby demos monthly contest, which is pretty cool if you are a developer.
• Contribute to the documentation if you feel you have the heart of a writer.

Contributing to the documentation can be done in several ways, depending on the time and the will you have to get involved:

• Writing new articles
  It’s the most time consuming contribution. However, it’s also the most useful to the most people.
• Localizing content
  If you are familiar with a language other than English it is a good idea to translate existing material into that language. Not everybody uses English all around the world and it’s important to make the Web accessible to anyone.
• Writing code samples
  Explanations are good, but examples are better. Many times, a good example can make things much more understandable than five paragraphs of rubbish text. So writing code samples is one of the most useful contributions and MDN really needs more.
• Reviewing content
  As I said before, the review process on MDN is really limited but contributors can explicitly ask for review (through a tagging system). These can be editorial reviews as well as technical reviews. (Look for NeedsTechnicalReview or NeedsEditorialReview tags on pages; remove the tag if the page is OK.) If you have a small amount of time, it’s the perfect contribution that will help a lot of people.
• Updating compatibility tables
  MDN’s open Web documentation is becoming more browser agnostic. To achieve that goal, there are many pages on MDN with browser compatibility tables. They allow users to know which API, element, attribute, or property is available for each browser. This is amazingly useful and it only take five minutes to add some compatibility data. Without a doubt, it is the easiest and fastest way to contribute to MDN.

One last tip. Documenting the open Web is a huge task that no one can perform alone. As a consequence, it’s a good idea to focus yourself on the topics you are interested in personally. If you want to work on a specific subject, know that MDN has “Topic Drivers” that can help you; feel free to contact them. They will be more than happy to assist you.

To complete this, there two introductory pages on MDN that can be quite helpful:

• Getting started
• To-do list

Conclusion

As you can see, contributing to MDN is quite simple. If you want to know more feel free to ask your question on IRC at irc.mozilla.org on the #devmo channel or through our mailing list/Google group dev-mdc. If you want to speak to someone, the best entry points are Eric Shepherd (aka Sheppy), Janet Swisher and Jean-Yves Perrier (Teoli). Those three people are Mozilla employes dedicated to MDN so don’t worry about contacting them; they signed up for it :-P

Long live the documentation :)

My involvement was to talk about the state of HTML5 when seen from a native market’s perspective, show some cool new technologies that need our input and take part in the browser panel to discuss current issues. Here are the talks and screencasts. Videos recorded by the organisers should follow soon.

Talk “Broken HTML5 promises – are we ‘appy?”

The main Mozilla presentation was about feedback on HTML5 we got at Mobile World Congress from mobile developers, how we as an HTML5 community fail to answer their questions and get tangled up in petty bickering over details instead and what Mozilla does to make HTML5 work across the board.

The slides with notes are available here and the screencast (with bad audio, sorry) is on vid.ly.

Breakout session: “The bleeding edge of HTML needs blood donors”

The breakout session (which was repeated twice) was much less of a “talk” but more of a show and tell in a smaller room. Therefore the screencast is a bit more raw but shows what you can do right now.

The slides with notes are available here and the screencast is on vid.ly.

The conference

All in all the conference was great value for money. All the speakers had great information to give and there was no “marketing talk” promising things that don’t work outside lab environments.

• Michael Mahemoff did a great job introducing the day with a “native vs. web knockout” talk.
• Paul Kinlan showed what is coming in Chrome and how Web Intents can change the way we solve app communication over the web
• Martin Beeby gave a glimpse of how the web can merge with newer devices and UX needs of users

Seb Lee-Delisle took all the browsers to the performance test to end all performance tests by animating millions of 3D particles and seeing which browser would be the one that can show the most without slowing down. In the end Firefox was the winner with 3695244 particles at 10FPS. Of course this is not a real measure (especially seeing IE10 was run in a VM) but it is always fun to see Seb code live.

I guess my favourite piece about the conference was that the browser panel was very much about answering people’s questions instead of trying to beat each other in being the browser that people should use. British understatement at its best.

Here is the obligatory “OMG! Awesome view!” photo from the roof deck in San Francisco, showing just some of the doc sprinters getting in the way of the view:

Here are only some of the things that happened in MDN docs as a result of this weekend:

• Will Bamberg researched and revamped the wiki page for Web development for mobile devices.
• Michael Beckwith:
  • made clarifying edits on a bunch of Web development articles
  • added some suggestions to Tips for authoring fast-loading HTML pages
  • added browser compatibility info to HTMLCanvasElement
  • added code examples to ::enabled, and BrowserID remote verification API
  • documented why and how a developer might want to run multiple Firefox profiles
  • added descriptions to tools listed on the Development tools page.
• Frederic Bourgeon documented the Flexible Box Layout Model, including Using CSS flexibile boxes and reference pages for:
  • flex-align
  • flex-direction
  • flex-flow
  • flex-item-align
  • flex-line-pack
  • flex-order
  • flex-pack
  • flex-wrap
• David Bruant wrote JavaScript data structures, and cleaned up defineProperty, moving non-reference examples to an additional examples page, and made improvements to the main JavaScript page.
• Anastasia Cheetham organized the ARIA documentation, added techniques for using about a dozen ARIA attributes, updated Using the slider role, and retired a bunch of pages on CodeTalks.org that are now superceded by MDN pages.
• Cory Gackenheimer made HTTP access control (CORS) browser-agnostic and added a compatibility table; split Using XMLHttpRequest into smaller chunks (including synchronous and asynchronous requests and sending and receiving binary data), made it more browser-agnostic, and added code examples; created Why BrowserID from various sources, and updated the NodeJS example in the BrowserID Remote verification API.
• Mark Giffin met with some of the Apps developers, researched app secrets, and updated In-app payments.
• Kevin Lim improved Using the Page Visibility API.
• David Mandelin drafted an article on SpiderMonkey GC.
• Jeremie Patonnier translated his blog post about getting started with MDN from French into English. Look for it soon on Hacks! He also documented SVG word-spacing and kerning.
• Jean-Yves Perrier hit all the CSS reference pages with the consistency stick, from animation to z-index. He also documented overflow-y.
• Florian Scholz updated DOMException and DOMError, and researched and documented the WebSMS API, including all the interfaces.
• Eric Shepherd finished documenting the Telephony API, set versions and priorities for bugs that need docs, and made updates for about twenty fixed bugs, and documented nsIPlacesImportExportService.
• Christian Sonne worked on speeding up the compatibilityTableAggregatorNoCache template, by making these fixes:
  • Guides and tutorials are no longer included in the compatibility table if they don’t contain one themselves
  • Fixed syntax of several compatibility tables
  • Fixed typo in template called from :invalid compatibility table
  • Introduced caches to individual content pages, meaning that the compatibility aggregator will have less work to do on a second run, if the first times out.
• Jeff Walden created a release notes page for (future) SpiderMonkey 1.8.8, and reviewed and made lots of small updates in the JSAPI reference.
• Kathy Walrath improved CanvasRenderingContext2D.
• Jonathan Wilsson added compatibility tables to CSS visibility, element.getBoundingClientRect and window.setInterval.

Addendum (2012-05-02): Vikash Agrawal created a code example for the contextmenu attribute; it’s not on MDN yet, but you can see it on github.

Highlights

There are a few of things we’d like to shine some extra light on here:

• Native Fullscreen Support in Mac OS X 10.7 “Lion”: Firefox can now use the native full-screen mode and button. It animates and behaves properly in that mode, like any other well-integrated application.
• Great news for gamers! The Pointer Lock API, sometimes called the Mouse Lock API, lets games better control the mouse, by removing the pointer and letting the application capture and handle the mouse move coordinates directly.
• The four default ways to search — using the search bar, the address bar, the contextual menu, or the home page, now all use the Google https search service in Aurora. This increase the security of your searches.
• The dev tools now allow easily inspecting pseudo-classes states: when hovering over an element with the dev tools activated, the contextual menu now lists the different states of the element, like :hover, :active, and :focus. When selecting one of these items, the element is locked in the associated state and can be inspected. That feature was already there in Aurora 13, but the interface to access it is now very convenient!
  
  

List of improvements

Here is a (more or less) complete list of the improvements.

DevTools

• New keyboard shortcuts have been added to the Source Editor JS module (used by the Scratchpad or the Style Editor) to quickly jump to the code block start and end.
• Still in the Source Editor module, it is now possible to add or remove a comment on a line or the current selection with one keystroke.
• Beside the new pseudo-class inspector, several improvements have been made to the infobar which has now an inspect button to the left and a node menu to the right (for example, it may be used to set the pseudo-class state on the node!)

DOM

• The Pointer Lock API has been implemented.
• A proposal for the replacement of MutationEvents, introduced in DOM Level 2 but deprecated in DOM Events Level 3, has landed, prefixed: instead of events, an API allowing callbacks to be registered has been crafted.
• New, with added performance, DOM bindings for non-list objects have landed. Currently XMLHttpRequest is the only non-list object using them. These bindings are often called the “Paris DOM bindings” as they were designed in that city.
• The SVGSVGElement has been fixed to be a DOM Element.
• HTMLProgressElement, the DOM object associated with the <progress> HTML element, was a HTMLFormElement. This was incorrect and has been fixed. It is a simple HTMLElement now.

Plugins

• Optionally, if the plugins.click_to_play preference is enabled in about:config, plugins will require an extra click to activate and start “playing” content. This mode improves the security of the browser and may be extended in the future to be activated by default in some cases. When on, site-specific permissions can be set.

Layout

• CSS text-transform and font-variant properties have been updated to match the spec and now handle the Dutch IJ digraph, the Turkic dotless and dotted i, and the Greek sigma lowercase characters correctly. This is big improvement for writing on the Web in these languages!
• Related to CSS transforms, the skew() function has been removed from the spec, so support has been removed from Firefox as well. It wasn’t a real skew function which designs the linear shear mapping transform and its effect is still achievable using the matrix() function.
• Directly viewed images now have a textured background.
• The character maps (cmap) have been optimized. Fonts with identical character coverage now share them. This lets Firefox use less memory, about 0.5 MB on a desktop system with few fonts, and up to 1.8MB or more on systems with a lot of fonts. The more fonts that are installed, the greater the savings. This was done as a part of the MemShrink project.
• SVG performance has been significantly improved.

User Interface

• The popup bubble containing a link URL that appears on the bottom of the page when hovering over a link is now longer when the URL doesn’t fit in it.
• As part of the Australis theme evolution project, the navigation bar buttons have been modified (on Windows only).
• The identity block has been redesigned. The favicon has been changed to show an icon describing the connection used:
• The page is served unencrypted (http).
  
• The page is served encrypted (via https) but some of its content comes from unencrypted servers.
  
• The page and its content is served encrypted (and the server uses a CV certificate).
  
• The page and its content is served encrypted (and the server uses an EV certificate).
  

Network

• At launch, tabs are no longer loaded in the background. Instead, they are now loaded when first selected, which improves response during the start-up of Firefox. This has been done as a part of the Snappy project.

Others

• Both the Internet Explorer and Safari migrators have been rewritten in JavaScript. Using asynchronous I/O, they don’t block the browser when they run and it improves their maintainability. This has been done as part of the Snappy project.
• On Linux, the $LANG system variable is now used when not able to locate a given dictionary in another way. Useful for system-wide installed dictionaries.
• For add-ons writers, the js-ctypes library has been extended. Variadic ctypes functions — that is, support for functions with a variable number of arguments — have been added.
• Several bugs in our WebGL implementation have been fixed (and workarounds for some common driver bugs added). We are close to WebGL 1.0.1 conformance, but your help is still needed.
• Extra flexibility has been added to the Garbage Collector (GC): it could previously be applied on a single compartment or on all compartments. Now it can also be applied on a set of compartments. This will let it be launched in more cases in the future, leading to a finer control of memory and of GC pauses.

Note: pdf.js and the new panel-based Download Manager, though they landed on Nightly, have not been lifted to Aurora 14 as they need further polishing. Similarly, support of GStreamer for videos, though it landed last week, has not been activated yet.

Help needed

A reader provided feedback that they don’t understand the domQuery example in the global Function object. It needs to be more clearly explained.

Web standards docs

• Vikash Agrawal added a code example to :only-child. Vikash is starting a Google Summer of Code project to add code examples for HTML and CSS reference pages. Good luck, Vikash!
• “aHref” created CSS border-image-outset.
• Eric Bidelman updated the compatibility info in Function bind().
• Frédéric Bourgeon updated the spec table for :invalid and added a French translation.
• David Bruant wrote an article on JavaScript memory management.
• Giles Burdett updated Writing Websocket client applications.
• Dan Callahan added privacyURL and toURL to navigator.id.get.
• Simon Chan added IE compatibility to Manipulating the browser history.
• Pamela Fox added the ‘download’ attribute to the <a> element.
• Fusionchess has been very active, including:
  • adding a section on embedded workers and a code example to Using Web workers
  • adding code examples to defineProperties, Bitwise operators, the structured clone algorithm, Blob, and window.location
  • creating pages for window.onbeforeprint and window.onafterprint
  • adding information on sending a Blob object to Using HMLttpRequest
• David Humphrey updated the text and examples of Pointer lock API.
• Husky add info about calling history.pushState to window.onpopstate.
• Kenan added IE Mobile compatibility info to window.btoa and window.atob.
• Jesper Kristensen updated Fixing common validation problems, including changing the examples to HTML5, and updated XHTML.
• Gijs Kruitbosch added compatibility info to JSON.
• Jeremie Patonnier created pages for the SVG attributes opacity, color-interpolation, color-interpolation-filters, and color-rendering.
• Jean-Yves Perrier created an article on CSS WebKit extensions, added Greek alphabet examples to CSS text-transform, added browser compatibility table and info to text-indent, and created a page for -webkit-box-reflect.
• Nickolay Ponomarev created Mutation events, and expanded and clarified error in the DOM event reference.
• Florian Scholz created a page for window.navigator.connection, added compatibility tables to MathML mfrac, mfenced, and mglyph, and updated vendor neutrality and browser compatibility on 17 MathML elements.
• Eric Shepherd created a page for XMLHttpRequestEventTarget, added a section on convenience functions to Touch events, and added an example of using a timeout to Using HTMLHttpRequest.
• Caesar Shinas added IE compatibility to Using media queries from code and MediaQueryList.
• Wes expanded Touch events to cover handling clicks and second touches.
• Ziyunfei translated or updated translations for something like a bazillion Chinese pages.

Mozilla technology docs

• A number of people contributed to Building B2G for Samsung Galaxy S2, including Ben Adida, Dietrich Ayala, John Hammink, Tobias Renz, Philipp von Weitershausen, and Zbigniew Braniecki.
• Will Bamberg created Bootstrapping BrowserID.
• Ian Bicking documented the ‘install’ and ‘uninstall’ events in
  navigator.mozApps.mgmt.addEventListener and added a code example to navigator.mozApps.mgmt.removeEventListener.
• Dan Callahan created a BrowserID Glossary, revamped the main BrowserID page, and updated the BrowserID FAQ.
• Luke Crouch started documenting Kuma, the new wiki platform that MDN will be moving to soon: Getting started with Kuma and Introduction to KumaScript.
• Malini Das added several function definitions to Marionette and added a section on running tests via make to Marionette Running tests.
• Fabrice Desré and Reuben Morais updated the code examples in
  Getting started with apps.
• Mike Conley documented how to use Thunderbird Filelink providers.
• Mark Giffin updated Apps manifest and the Apps JavaScript API.
• Jeff Griffiths revamped the Boot to Gecko landing page and created Using Gaia using Firefox Nightly.
• Joliclic added a section on returned values to Declaring and calling functions in Using js-ctypes.
• Geoff Lankow updated nsIFile based on its merger with nsILocalFile in Gecko 14.
• Philipp von Weitershausen created Writing a web app for Boot to Gecko,
  Building B2G for Samsung Nexus S and updated Setting up the Boot to Gecko build environment.

Mozilla project docs

• Joel Maher added a section on Mochitest-Robocop to Mozilla automated testing.
• Pc.wit.tt created Rebranding SpiderMonkey (1.8.5).
• Hassadee Pimsuwan added Thai to the list of MDN translations.
  Translators are also needed for Spanish, German, Greek, Russion, traditional Chinese, Hebrew, and Romanian.
• Thierry Régagnon improved a number of the MDN templates for the French translation.