fidzu : Mozilla

We do like reading in Mozilla's Developer Engagement Team - here are our latest recommendations for you!

Weekly links November 10th 2011

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 mean.
The picks this week are:

Christian Heilmann

A good explanation on Firefox's Full Screen API and of course the 700,000th bug on Firefox's bugzilla.

If you want to read more tips or discuss the web with Christian, he's available on Twitter as @codepo8.

Eric "Sheppy" Shepherd

Jeff Griffiths

The new ThemeRoller app for jQuery Mobile looks awesome!

If you want to read more tips or discuss the web with Jeff, he's available on Twitter as @canuckistani.

Joe Stagner

Building Web Pages with Local Storage.

If you want to read more tips or discuss the web with Joe, he's available on Twitter as @MisfitGeek.

Rob Hawkes

Here is the draft report from the W3C Games Community Group Summit in San Francisco earlier this month. After playing with the Joystick API this week I'm excited to see how browsers and game developers can work together to make the Web a viable platform for gaming.

If you want to read more tips or discuss the web with Rob, he's available on Twitter as @robhawkes.

Robert Nyman

25 Secrets of the Browser Developer Tools - a good overview of various web browser developer tools and in-depth information about them.

If you want to read more tips or discuss the web with Robert, he's available on Twitter as @robertnyman.

10 Nov 2011 2:54pm GMT

I'm in Berlin this week to attend this weekend's MozCamp EU; because I'm a dork I really really like having some sort of local data network access, in particular for using google maps on my unlocked Android phone. Having mobile data access has completely changed how I travel, I'm much more likely to just really explore a place than I would without access to google maps. So here's my process for getting cheap mobile data in Berlin:

1. took the U6 -> S line trains to Alexanderplatz to get to the Alexa Mall ( http://g.co/maps/rv2hz, see map below )
2. went to Media Markt ( think German Best Buy ), bought a FONIC.de 10 euro SIM card
3. back at the Tryp hotel where I'm staying, I registered online with fonic.de to activate the sim. There is no English localization of the site and my German is terrible so I had a second window open to google translate to get through it.
4. in order for the data plan to really start, I had to set my Android phone to 'data roaming' mode.

This will get you a flat rate of 500MB of data, plus relatively cheap text and calling! Sadly, you do need to jump online to register the sim, this is definitely less convenient than what I got last month in London, where they sell flat-rate data sims from vending machines at Heathrow.

Alexa / Media Markt:

View Larger Map

10 Nov 2011 1:07pm GMT

This year's Velocity EU conference had a special presentation round where browser makers talked about the performance of their specific products. I was invited last minute to represent Firefox and originally was asked to show benchmarks, impressive demos and how we compare to others. As browsers get released in very short intervals these days, this doesn't quite make sense any longer - at least to me.

Funnily enough the other browser representatives took the same approach so I was happy to see that we agreed that we are beyond number-comparisons and head to head browser war on performance.

My talk "Accelerating the overall web experience" covered other things, like that the choice of which browser to use lies with the users and there is not much we can do to change that. I also pointed out that users will find a way to make our browsers slow, no matter how hard we try and that in a lot of cases third party add-ons and debugging tools are to blame for an impression of slowness.

I ended by showing how the new developer tools in Firefox empower developers to perform much better in finding bugs and fixing them - a part of performance that is not easily measurable but very important.

You can see the slides here (left+right to go back and forward, down for next bullet point and N to toggle notes) or read them as an HTML page:

There is also an audio recording of the talk on archive.org:

All in all it was good to see that all browsers are getting faster and faster and we all see this as a given rather than a goal.

10 Nov 2011 12:11pm GMT

Good free software is a worthy goal in itself, and I hope that readers who come looking for ways to achieve it will be satisfied with what they find here. But beyond that I also hope to convey something of the sheer pleasure to be had from working with a motivated team of open source developers, and from interacting with users in the wonderfully direct way that open source encourages. Participating in a successful free software project is fun, and ultimately that's what keeps the whole system going.

- Karl Fogel, Producing Open Source Software

10 Nov 2011 9:36am GMT

(Photo : Eduardo)

Cette photo a été prise durant Latinoware. On y voit, de gauche à droite : Armando Neto, Evelyn Urcullú, Lourdes Castillo, Eduardo Urcullú, Reuben Morais, Rodrigo Padula (t-shirt jaune), Fernando Silveira et Guillermo Movia.
Trois communautés se mêlent ici : Paraguay, Brésil et Argentine.
Evelyn et Eduardo avaient caché des enveloppes sur les lieux de l'évènement avec des prix à l'intérieur, chaque personne qui trouvait une enveloppe pouvant réclamer le prix.

Bonjour à tous !

This photo was taken during Latinoware. We can see, from left to right: Armando Neto, Evelyn Urcullú, Lourdes Castillo, Eduardo Urcullú, Reuben Morais, Rodrigo Padula (yellow t-shirt), Fernando Silveira, Guillermo Movia.
There are three communities meeting there: Paraguay, Brazil and Argentina.
Evelyn and Eduardo had hidden some envelope in the event field with prizes inside, everyone that found one, could reclaim the prize.

Bonjour everybody!

10 Nov 2011 9:00am GMT

10 Nov 2011 4:00am GMT

10 Nov 2011 4:00am GMT

Mozilla is growing, and we have to grow our infrastructure right along with it. A lot of this just happens behind the scenes as we are buying and installing new gear every month. For today's post I thought I would give an insight into the broad range of servers we have in the ordering/shipping process right now.

if only it were this easy...

• New mailbox store - Our last Zimbra hardware upgrade was back in April. We are at the point now where we need to shed some mailboxes off to a second server to help with load. This is not so much due to the growth in the number of mailboxes we host, but because most of our users have multiple clients hitting Zimbra all of the time. Desktop, laptop, cellphone, tablet.. multiply that by the number of mailboxes and we have to start spreading the love to an additional server before it becomes a problem.
• New VMWare servers - More VM space for QA, Labs, and more!
• New load balance test box - We have run into issues with our blade-hosted load balancer boxes. We will swap a couple out in one of our data centers for some beefier boxes and 10gig ethernet connections. Depending on our results here we may be reworking our existing load balancing clusters to fit this new model. In addition, this will provide guidance for our new data center in the spring.
• New gear for addons.mozilla.org - a whole rack of blades, in fact! We are also awaiting the arrival of some Fusion IO flash accelerator cards for the AMO database nodes. This will greatly increase the speed of I/O for those database nodes, ending up in faster results and more capacity. We did the same for the bugzilla databases recently with great success.
• Elastic Search servers for Socorro - 8 1U servers (aka "pizza boxes") are on their way for Socorro.
• New servers and infrastructure for China - We are prepping infrastructure for a new data center in China that will provide plenty of room and power where our current data center is tight. This allows us to source some sites locally there as well as cache others there for improved performance throughout the region.

On a logistical note, we are getting a new block of space in our Phoenix data center that all of this gear will go in once it is ready (except for the China servers). We are close - just a few more pieces to that puzzle and we will start racking this new gear.

That's all for now, it is time to get back to obsessing over FedEx trackers and logistical details. Next week, we invent teleportation.

10 Nov 2011 3:25am GMT

The following is a guest post by Henri Sivonen:

In Firefox 8, we've added support for insertAdjacentHTML(). It's an ancient feature of Internet Explorer that has recently been formalized in HTML5 and then spun out into the DOM Parsing specification. The bad news is that Firefox is the last major browser to implement this feature. The good news is that since other major browsers implement it already, you can start using it unconditionally as soon as the Firefox 8 update has been rolled out to users.

Basic Usage

insertAdjacentHTML(position, markup) is a method on HTMLElement DOM nodes. It takes two string arguments. The first argument is one of "beforebegin", "afterbegin", "beforeend", or "afterend" and gives the insertion point relative to the node that insertAdjacentHTML() is invoked on. The second argument is a string containing HTML markup that gets parsed as an HTML fragment (similar to a string assigned to innerHTML) and inserted to the position given by the first argument.

If the node that insertAdjacentHTML() is invoked on is a p element
with the text content "foo", the insertion points would be where the comments are in the following snippet:

<!-- beforebegin --><p><!-- afterbegin -->foo<!--
beforeend --></p><!-- afterend -->

The "beforebegin" and "afterend" positions work only if
the node is in a tree and has an element parent.

For example, consider the following code:

<div id=container><p id=para>foo</p></div>
<script>
  document.getElementById("para").insertAdjacentHTML("beforeend", "<span>bar</span>");
  console.log(document.getElementById("container").innerHTML);
</script>

This code produces this log output:

<p id="para">foo<span>bar</span></p>

Well, that does not look particularly special. In fact, it looks like something that could have been done using plain old innerHTML. So why bother with insertAdjacentHTML() when element.innerHTML += "markup"; already works?

There are two reasons.

• insertAdjacentHTML() doesn't corrupt what's already in the DOM.
• insertAdjacentHTML() is faster.

Avoiding DOM corruption

Let's consider the DOM corruption issue first. When you do element.innerHTML += "markup";, the browser does the following:

1. It gets the value of innerHTML by serializing the descendants of element.
2. It appends the right hand side of += to the string.
3. It removes the children of element.
4. It parses the new string that contains the serialization of the old descendants followed by some new markup.

The old descendants might have been script-inserted to form a subtree that doesn't round-trip when serialized as HTML and reparsed. In that case, after the operation, the tree would have a different shape even for the "old" parts. (For example, if element had a p child which in turn had a div child, the subtree wouldn't round-trip.) Furthermore, even if serializing and reparsing resulted in a same-looking tree, the nodes created by the parser would be different nodes than the nodes that were children of element at first. Thus, if other parts of the JavaScript program were holding references to descendants of element, after element.innerHTML += "markup"; had been executed, those references would point to detached nodes and element would have new similar but different descendants.

When additional content is inserted using insertAdjacentHTML(), the existing nodes stay in place.

Better performance

Serializing and reparsing is also what leads to performance problems with the element.innerHTML += "markup"; pattern. Each time some more content is appended, all the existing content in element gets serialized and reparsed. This means that appending gets slower and slower, because each time there more and more previous content to serialize and reparse.

Using insertAdjacentHTML() can make a big difference. For testing purposes, I started with an empty div and ran a loop that tried to append as many tweets as possible to the div in five seconds. A tweet is actually rather large when you count all the mark-up that implements @mention linkification, the name of the tweeter, retweet and favoriting UI, etc. It weighs about 1600 characters of HTML source-most of it mark-up.

On the computer that I used for testing, the innerHTML way of appending managed to append only slightly over 200 tweets in five full seconds. In contrast, the insertAdjacentHTML("beforeend", ...) way of appending managed to append almost 30,000 tweets in 5 seconds. (Yes, that's hundreds versus tens of thousands.) Obviously, real Web apps should never block the event loop for five seconds-this is just for benchmark purposes. However, this illustrates how the innerHTML way of appending becomes notably slower as more and more content accumulates to be serialized and reparsed each time.

At this point, some readers might wonder if insertAdjacentHTML() offers any benefit over createContextualFragment(). After all, conceptually insertAdjacentHTML() creates a fragment and inserts it.

Using createContextualFragment(), my test manages only slightly over 25,000 tweets in five seconds, while using insertAdjacentHTML() manages slightly under 30,000. This is because Gecko accelerates insertAdjacentHTML() when the insertion point has no next sibling (only for HTML though-not for XML so far). The "beforeend" insertion point never has a next sibling and is always accelerated (for HTML). The "beforebegin" insertion point always has a next sibling (the node that insertAdjacentHTML() was invoked on) and is never accelerated. For "afterbegin" and "afterend", whether the operation is accelerated depends on the situation.

In conclusion, you can make your Web app perform better by using element.insertAdjacentHTML("beforeend", "markup"); where you currently use element.innerHTML += "markup";.

10 Nov 2011 3:02am GMT

Adobe is killing Flash, as a plugin for mobile. This shouldn't come as a surprise to anyone who works on the web. Anyone who knows me knows I've bet on HTML5 since the beginning and haven't been ashamed to say it. I don't do Flash. To quote Adobe:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.

I strongly suspect that even this use case is limited and will experience the same fate as the Flash plugin within the next 24-36 months. HTML5 is supported by browsers, a browser is shipped with the OS and is highly optimized for what it's running on. It's also the ultimate in cross-platform. Why write Flash when you can do something for every platform and not rely on a vendor to abstract you?

Platforms like PhoneGap bridge the world of Apps and HTML5 quite nicely. Adobe bought Nitobi which develops PhoneGap, but PhoneGap is also going to Apache Software Foundation which means Adobe's ability to derail the project would be somewhat limited if they wanted to go that route.

Quite a few Apps use HTML/JS extensively already. HTML5′s success is despite Apple essentially crippling the use of HTML5 in native apps by preventing UIWebView from taking advantage of the Nitro engine. If/when Apple gets to fixing this another barrier will be gone. I suspect Apple will eventually make scrolling that doesn't suck on iOS easier. Right now Joe Hewitt's Scrollability is likely your best bet.

Adobe goes on to say:

However, HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. We are excited about this, and will continue our work with key players in the HTML community, including Google, Apple, Microsoft and RIM, to drive HTML5 innovation they can use to advance their mobile browsers.

Interestingly they left out that little browser vendor Mozilla. Perhaps because they are most likely targeting WebKit on mobile and that's the common tie between those companies sans-Microsoft which they need IE support. If Adobe wants a future here they should learn quick that you can't ignore platforms. My advice to Adobe is to make sure their solution allows developers to bring their product to any modern browser on any device.

Flash is the last plugin with real usage even on the desktop. This is the first step towards the concept of plugins in the browser going away. It's unlikely many will see a need to go HTML5 on mobile and develop a separate Flash code base to do the same thing on a desktop. The name of the game these days is write once, run anywhere (credit to Sun for the slogan). Today marks the start of the decline of Flash.

As Brendan Eich best put it: "Always bet on JavasScript". I have and I continue to do so. The Open Web is winning. Slowly but surely.

10 Nov 2011 2:30am GMT

BrowserID is an initiative to provide the web with a better way to sign in. The web is a connected collection of resources and you should not have to have a user name and password for each of them when you could use the web instead.

Today we show you a screencast of how easy BrowserID makes it to login to a web site. For this, we'll look at how the login flow for an existing BrowserID user works the first time they log in on a new website. Our example website is OpenPhoto, a hot new photo sharing app that keeps users in control of their data.

Screencast of logging into OpenPhoto with BrowserID

Get involved:

BrowserID needs your help to grow and become a weapon of choice in the fight against insecure and annoying login systems. The great thing is that now is the time where you can be part of this.

• Implement BrowserID
• Install OpenPhoto
• Contribute to the Field Guide

10 Nov 2011 1:03am GMT

09 Nov 2011 10:43pm GMT

09 Nov 2011 10:39pm GMT

C++ default operators and the sole-ownership idiom

Often a C++ class will solely manage some value: for example, a GtkWindow* or a void* for malloc'd memory. The class will then release ownership in its destructor as appropriate. It would be extremely problematic to release ownership multiple times - think security-vulnerability-problematic. C++ copy construction and default assignment exacerbate this issue, because C++ automatically generates these methods for all classes, even when the default behavior breaks sole-ownership. The C++98 idiom solving this is to privately declare a copy constructor and a default assignment operator, then never define them:

struct Struct
{
  private:
    Struct(const Struct& other);
    void operator=(const Struct& other);
};

Declaring the methods privately prevents any code but friends of Struct from calling them. And by never defining them, even such friends will cause a link-time error if they try.

Disabling the default operators in C++11

Once you're familiar with this idiom it's not too bad. But initially, it's pretty unclear. And nothing prevents someone from actually defining these methods. (They could only be used by Struct or friends of Struct, to be sure, but for sufficiently complex code it's possible someone might make a mistake.) C++11 improves upon this trick by introducing deleted function syntax:

struct Struct
{
  private: // no longer necessary, but doesn't hurt
    Struct(const Struct& other) = delete;
    void operator=(const Struct& other) = delete;
};

Deleted functions are effectively removed from name lookup: using, defining, or referring to a deleted function produces a compile error - far better than a link error or, even worse, no error at all.

= delete support in MFBT

The Mozilla Framework Based on Templates now includes support for declaring a function only to prevent its use (or use of an inherited version). The MOZ_DELETE macro encapsulates this support:

#include "mozilla/Types.h"

struct Struct
{
  private:
    Struct(const Struct& other) MOZ_DELETE;
    void operator=(const Struct& other) MOZ_DELETE;
};

MOZ_DELETE isn't as readable or understandable as = delete, but it's searchable, and the comment next to its definition will clarify matters. If the declarations are private, MOZ_DELETE is just as good as the traditional idiom, and in compilers supporting C++11 deleted functions it's better.

Which compilers support C++11 deleted functions? I'm aware of GCC since 4.4, Clang since 2.9, and ICC since 12.0. Rightly, if unfortunately, you must specify -std=c++0x or similar to use deleted function syntax without causing a warning. For various reasons Mozilla can't do that yet, so MOZ_DELETE only produces the C++11 syntax when compiling with Clang (where we can pass -Wno-c++0x-extensions to disable the warning). I'd love to see it use C++11 syntax in GCC and ICC as well, but I don't have the time to solve the -std=c++0x problem now, or to figure out another workaround. I've filed bug 701183 for this problem - help there is much appreciated.

Summary

Use MOZ_DELETE when declaring any method you will intentionally not implement. It'll work better, and produce better errors, in some compilers. Those compilers don't include GCC or ICC yet, but with your help they could. Any takers?

09 Nov 2011 10:12pm GMT

tl;dr: We're settling into an Agile process for MDN with daily standups and weekly planning. In the last few months we've added and enhanced developer profiles, events, demos dev derby, and other MDN features. We've also restored, added, and enhanced drafts, review flags, search, article properties, section editing, and authentication in the new wiki. I'll try to write status posts more frequently - each time we make a release, if possible.

Agile

Since my last MDN & Kuma progress post, we've settled into a regular, yet customized, Agile methodology in the MDN team with our agile Bugzilla JS tool. We've pushed MDN 0.9.8, 0.9.9, 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 thru it relatively smoothly. We've learned and adapted a few techniques in our Agile process worth noting:

Daily standups on IRC

1. What have you done since we last met?
2. What do you plan to do until we meet next?
3. Are you blocked by anything?

By far the 3rd question here is the most important. The first questions are mostly intended to lead into the 3rd. Our scrum-master (now me) is tasked with removing any and all blockers as much as possible - usually chasing down people in other groups from whom we need something (IT, DevEngage, Legal, Security, etc.)

(Bi-)Weekly Retro & Planning Poker

We push code on Tuesdays, so we alternate between post-/pre- and mid-sprint planning meetings. Mid-sprint planning meetings are shorter and faster, little more than a standup. We use an etherpad template for a running minutes of our weekly Wednesday meetings. The basic format is:

1. Retro - what's go[(ing)|(ne)] good or bad in the sprint?
2. Discuss - general items to discuss, usually flowing from Retro
3. Planning (post/pre-sprint only) - re-assess bugs carried over from previous sprint, use planningpoker.com to estimate the current sprint backlog in bugzilla

Status

We're developing major features for both MDN and the upcoming wiki.

MDN

• Developer profiles
  My MDN profile is missing demos because I haven't made any yet. We want to hook this up with Mozillians.org in the (near) future.
• Events
  We've tried to make the MDN events page a comprehensive resource to find the events Mozillians attend. Inspired originally by Christian's site for Mozilla events.
• Demos & Dev Derby
  We've done significant work on the Dev Derby feature - streamlining the process and clearing out bugs. This is one of my favorite MDN features. When I need to show anyone cool web technology I can open the MDN demo studio and inevitably find something way cool with canvas, video, audio, and webgl.
• Miscellaneous
  We're also finding and squashing bugs as often as we can. We finally restored production server error emails, so we should be much better about squashing bugs that real users are are hitting. And we're trying to add smaller optimizations and fun features as often as we can.

I enjoy enhancing MDN in addition to building the new wiki system. The wiki is important and should help us take more control over our docs, but it's still behind-the-scenes; I like shipping code to a production site that helps people, especially developers, immediately.

Wiki

We hope to soon (by the end of the year) run the new wiki side-by-side with MindTouch so we can work from a single line of code and allow testers to compare MindTouch with the new wiki on the same server. But so far we've developed the following features on the separate kuma wiki staging server:

• Drafts
  We use localStorage to periodically save the editing session so a writer doesn't lose precious work if their client crashes.
• Review Flags
  We added review flags for both technical and editorial review.
• Search
  We restored the Sphinx-powered search backend we inherited from SUMO/kitsune (just in time for them to move on to ElasticSearch). We still need to restore all of the search frontend and ancillary features.
• Page Properties
  We restored and refactored document properties we inherited from SUMO/kitsune.
• Section Editing
  We added section editing to the wiki - our first major modification to the wiki functionality we inherited from SUMO/kitsune.
• Authentication
  We're in the middle of switching MDN user authentication from MindTouch to django. We will run both authentication backends together, first django then falling back to MindTouch and auto-registering and migrating users to django authentication as they log in.

The wiki work is going pretty well, but we still have a couple of major hurdles to clear: data migration & user scripting. We are already investigating data migration a bit, and once we start migrating data over it should help direct our work on user scripts. In my opinion, we can see light at the end of the tunnel but we're still watching out to avoid potential train-wrecks.

The rest

Outside of MDN, I helped pull together an HTML5 track for Tulsa Tech Fest, helped organize a Tulsa Hackathon with Tulsa Web Devs, and I participated in Startup Weekend Tulsa. At SWT we started a quick web app on top of the TRIF project from Hackathon called OttoZen to send an SMS alert to someone when there's a traffic incident on their commute. It's making us consider building a broader Data/App site for Oklahoma. We'll see.

From now on I'll try to make a status post every time we make an MDN release.

09 Nov 2011 10:03pm GMT

This is the first in a series of posts about new or recently improved content on MDN. This series will alternate with Wiki Wednesday posts, which will switch to every other week.

The purpose of this series is to highlight articles that have changed recently, as well as to recognize the contributors who did the work. This doesn't include every change, just "significant" ones. Future posts may be a bit shorter, as they'll cover only the two weeks since the previous "state of the docs" post.

Web standards docs

Jean-Yves Perrier documented the <bdi> element. It allows inserting spans of text with unknown directionality, like text coming out of a database, in the middle of text with a known fixed directionality. He also updated the CSS unicode-bidi property to describe the two new values: isolate and plaintext, which are used to implement correctly bi-directionality for each HTML element (including, but not only, <bdi>, <bdo>, <pre> and <textarea>).

Jean-Yves rewrote the docs for the CSS property text-overflow, to account for the new extended two-value syntax and the new allowed string values, as well as adding new examples.

Jean-Yves also added pages for columns, updated column-width and column-count, and Using CSS multi-column layout.

Paul Irish made a rash of updates:

• Linked to a <canvas> polyfill for image-rendering for crisp-edges/optimize-contrast
• Added an example to show how to easily prettyprint with JSON.stringify().
• Created the page for node.contains().
• Added a compatibility table for img[crossorigin]
• Documented that getComputedStyle can get pseudo-element styles. Also it can be used from the window object.
• Documented creating and triggering custom events (which he had always wanted spelled out)
• Added a compatibility table to table.insertRow().

Kevin Lim continues to improve the IndexedDB docs:

• Added code examples to IDBEnvironment and IDBIndex.
• Updated IDBCount.
• Added prefix-handling code to several code examples.
• Beefed up basic concepts and best practices in IDBDatabase, IDBTransaction, and IDBIndex.

fusionchess added a code example to Using files from web applications.

Aaron Leventhal updated the ARIA page with lots of doc and resource links, and wrote new articles on:

• live regions
• how to file ARIA-related bugs
• examples
• alerts for accessible forms
• multipart labels for forms
• ARIA widgets

If you're interested in ARIA and accessibility, please help out with these docs. If you're not an expert, you can help identify where there are gaps, or things that don't make sense. Accessibility geeks might also be interested in the free-aria Google Group.

New pages!

• Initial documentation for the <frame> and <frameset> HTML elements, by avsaro.
• SVG as an image by Dholbert.
• Responsive Web design, by Janet Swisher; if you know of good resources that are not listed there, please add them.
• Scaling of SVG backgrounds and Drawing DOM objects into a canvas, by Eric Shepherd.

Help wanted!

Want to write an article on CSS positioning? That is, how positioning properties for margins, padding, etc. work together. MDN does not have this topic covered yet. Or, if you've already written such an article, would you be willing to contribute it to MDN under a CC-BY-SA license?

Check out the MDN Getting started page. If you have questions, drop into #devmo IRC channel on irc.mozilla.org, or post to the dev.mdc discussion forum.

Mozilla-specific documentation

Henri Sivonen wrote about HTML parser threading in Gecko.

jbeatty improved Patching a localization, Create a new localization and several other localization-related pages.

Tom Schuster added to the SpiderMonkey JS API reference for:

• JS_GetEmptyString
• JS_NewDateObjectMsec
• JS_NewDateObject

Eric Shepherd wrote up complete reference docs for the new JavaScript Debugger API. However, the user guide for the Debugger API needs a lot of attention. We don't have any examples at this point. A sample add-on that uses the API should be written, but even the JSAPI team hasn't done one yet.

Firefox 8 was released on November 8, and Firefox 8 for developers is complete except for a few lower-priority items.

decoder created an article on Testing with Linux on ARM architecture using QEMU.

Jorge Villalobos updated several pages of the XUL School tutorial.

Eric Shepherd created an article for the Mozilla Developer Guide on Getting documentation updated.

09 Nov 2011 9:52pm GMT