Contributing

WebAPI work is being tracked by Mozilla bug 673923. Find a dependent bug that interests you (and is unassigned), and assign it to yourself.

Documentation

This wiki page's purpose is mostly to be able to track the advancement of the work on the different APIs covered by the WebAPI team and help working on those. If you are interested in documentation for these Web APIs, you should look at the following MDN documentation page: https://developer.mozilla.org/docs/WebAPI

APIs

Here's a list of the APIs that we're working on. Some of them are done, and some of them we haven't gotten further than acknowledging that we probably need them.

Planned for initial release of B2G

Unless otherwise noted, APIs listed in the table below were available in Firefox OS v1.0.1 or will be available in v1.1.

implemented but requires explicitly turning on the preference on this platform

not implemented for this platform

not currently planned for this platform

Process

A draft specification and prototype implementation of new Web APIs will be discussed publicly on our mailing list and at our public meetings (see below). Once we have an API that we feel that we are satisfied with, we will submit the new API for standardization to the W3C. See also tips for standardizing APIs.

The goal is to standardize all APIs.

Design Principles

Security

Security will be a central aspect of all the APIs that we design. We wouldn't want any random webpage to be able to read the user's contact list, or able to issue arbitrary commands to any USB device which is hooked up to the user's computer.

In some cases the solution will be to simply ask the user, like we do today for Geolocation for example. In other cases, where security implications are scarier or where describing the risk to the user is harder, we'll have to come up with better solutions.

This is an area where we're still doing a lot of research. I really want to emphasize that we don't have all the answers yet, but that we plan on having them before we roll out these APIs to millions of users.

Low Level vs. High Level

One question that often comes up, is should we do low level APIs, like USB access, or high level APIs, like camera access?

In many cases we are going to want to do both high level and low level APIs, with an initial priority on low level. High level APIs will let us create more friendly APIs, which are both easier to use for developers, and better for users since we can provide better security guarantees. However low level APIs will provide support for a wider range of hardware and use cases and will get the browser out of the critical path for innovation.