Roadmap Scratchpad

Important Preamble That You Should Read, Unlike All The Other Ones That You Just Skip To Get To The Good Stuff

The version numbers, branch names, feature lists, schedules, and indeed basic physics of this roadmap are still very much under discussion. Please do not place large bets or name children around the elements of this roadmap at this time. We have been fortunate to have feedback and input from a number of smart and energetic people, and seek much more such input to help refine this document over the course of the development it describes.

About This Roadmap And Branches/Releases

This roadmap describes the planned capabilities of the Mozilla platform, often known as "Gecko", in the 1.9 release. The product delivery vehicle for this platform will be explored, discussed, and refined in another roadmap process, to which this document will soon link.

So, this is the "platform" roadmap. The other document, the "product" roadmap, builds on this one to detail the plans for Firefox 2 and Firefox 3. Products such as Thunderbird, and projects such as Sunbird, will likely adapt their roadmaps to match the product/platform pair centered on Firefox and Gecko.

The work described in this document will be performed -- in several cases it is already being performed -- on the trunk of Mozilla CVS, with the 1.8 branch preserved largely intact. Some of the features listed below may be pulled forward into that 1.8 branch if needed for product releases off that branch, but you shouldn't count on it. We will preserve all API (frozen or not) compatibility on the 1.8 branch, so only selected additional APIs are thinkable.

Major Areas Of Development

There are several major areas of development for Gecko 1.9, intended to serve both the applications built on top of it (chiefly Firefox 3) and applications built on the web which need or would benefit from improvements in web technology. Many of these web-facing enhancements will be implementations of existing standards, in whole or in part. Some will be new standards.

A rough attempt to categorize these development areas can be found below. Some elements could reasonably be categorized multiply, so tags would be better than categories. Please bear with our taxonomy.

Graphics and layout capabilities

Graphics and layout changes represent some of the most invasive work proposed for the Gecko 1.9 development cycle. They form the core of the architectural shifts in 1.9, and are considered to be the most difficult and riskiest elements.

To manage risk, this roadmap proposes that major graphics and layout work -- especially the cairo-substrate and reflow-branch changes -- be scheduled as early as possible, in staged landings. Both of these work items have meaningful development behind them as of this writing (October 2005), but both will also require significant additional work to reach a level of completeness (including performance) that will allow them to be made default on the trunk.

The changes most graphical in nature (SVG, Canvas, XUL2D) depend on a switch to the cairo graphics library as the fundamental display architecture for Gecko, work on which is already well underway. The aim of shifting to cairo is to bring modern, hardware-accelerated 2D graphics capabilities to the whole of the web, without requiring proprietary plugins or rendering obsolete the broad and rich set of web authoring techniques developed over the past decade.

The layout changes -- see also the "XUL' and XBL2" section of this roadmap -- center around David Baron's "reflow branch", the aim of which is to eliminate reflow commands and types, and significantly reduce the complexity of the Gecko layout model. This is the first change to global layout architecture in several years, and it is hoped that it will address many problems related to incremental reflow. In addition, it should simplify some problems that are not practically soluble with the current architecture, such as support for inline-table.

JavaScript 2

The development of the Mozilla suite of applications, from the earliest days of Seamonkey to the current Firefox 1.5 release, has demonstrated the promise of developing significant infrastructure and application logic in JavaScript, rather than the fragile world of Mozilla's portable C++ dialect. Over the course of that development, though, many limitations in the language and our implementation have come to hinder our development efforts, and the JavaScript 2 work in Gecko 1.9 seeks to address many of them.

Building upon the "Edition 4" proposals before the ECMA-262 technical group responsible for standardizing the ECMAScript dialect of JavaScript, this work will cherry-pick, for early implementation, elements that are key to developing in JavaScript at the scale required for applications like Firefox. (N.B. that this is not a wholesale adoption of the JavaScript 2 proposal written several years ago by Waldemar Horwat, though the current Edition 4 design is similar in many ways.)

In order to test the draft Edition 4 specification, we will implement all of it in due course, but that may not happen till after Gecko 1.9 is all but done. So it may be that 1.9 ends up shipping a "JavaScript 1.9" -- time will tell. The goals are to materially improve the productivity of JS hackers working in Firefox and other XUL apps, and to prove the soundness of the new edition of the language.

Apart from all the new language features (for more details, stay tuned to the roadmap blog), the JS2 implementation should be significantly faster and easier to debug, both from script and from a graphical debugger such as Venkman. Debugging support in major IDEs is possible (more than possible in one IDE that's already working on it).

Python for XUL

Significant potential contributors in both the Python and XUL application development communities have long wanted access to Python's set of libraries and its capabilities as an application development language. So in addition to JavaScript, which is the default web and XUL scripting language, we plan to extend the reach of Gecko and XUL to the Python world.

Mark Hammond's work on PyXPCOM and a language-neutral DOM is well under way as of October 2005, and we believe that the glue code and bindings will be slim enough to be part of a default XULRunner or Firefox distribution when the 1.9 cycle is complete.

(N.B.: Mozilla does not intend to distribute the C-Python runtime with its applications or frameworks, so application developers who wish to take advantage of these capabilities will need to provide for this dependency in their installers or packaging. Stub or streaming installer capabilities in the Firefox/XULRunner based on Gecko 1.9 will probably help a great deal to ease the extra download for Python-less users.)

XUL' and XBL2

The XUL and XBL languages have served Mozilla development very well, and are often taken as a model for XML-based UI development in other circles. In some cases, however, our implementations or their old specifications are incomplete, inconsistent, insufficiently robust, or not amenable to some important use cases (including remote XUL applications or rich mixing with other content types such as HTML or SVG). We seek to address these limitations, and generally improve the XUL and XBL development experience, with work in Gecko 1.9.

The XBL work is based on an existing design by Ian Hickson and David Hyatt, currently being developed in the mozilla-xbl list. Pending the complete specification, we can't be sure that all of XBL2 will be implemented in the 1.9 timeframe, but we are committed to at least an improved attachment model, clearer lifecycle semantics, and scripting language neutrality. These are prerequisites for desired 1.9-era application and platform features.

XUL work in Gecko 1.9 will not undertake to create a shining XUL2 jewel, but will instead work to preserve compatibility with "XUL1" where practical, and make clean breaks where unavoidable. Hence the tentative name XUL' (XUL Prime).

Improvements to the XUL box model, based on the specification work started by Hixie and Hyatt, should provide a more consistent and flexible layout model for XUL developers, and help to rationalize XUL's interactions with other content types. This box-model work has been proposed for standardization via the W3C CSS working group. Much of the gain in any "shining XUL2 jewel" plan would likely be delivered by these box-model fixed, improvements, and cross-content rationalization, rendering the former not only a non-goal but also a non-issue.

Web app deployment and capability improvements

The recent resurgence in Web application development as demonstrated the significant power and capability of Web technologies, as well as some key areas of desirable improvement.

Chief among these is a client-local storage capability, which need is not sufficiently addressed by HTTP cookies. Cookies provide limited storage space (on the order of a few kilobytes), require the application developer to manually encode and decode any structure more complex than a simple string, and are transmitted back to the server on each request. In response to these limitations, some application developers are using the Flash plugin simply to gain access to a reliable and capable local store. Ian Hickson and the WHATWG have specified a simple but powerful client-local storage interface that addresses these concerns, and eliminates the dependence on proprietary plugins.

(There is a proposal circulating that Mozilla develop and distribute a small JavaScript library to abstract away different local storage technologies. Released in advance of Gecko 1.9, it would likely use Flash underneath, and perhaps IE's "user-data" capability. An updated version of the library would simply drop in and use the WHATWG client-local storage API if provided by the host browser.)

Another limitation often decried by developers of rich Web applications is the lack of a reasonable offline execution model. Mechanisms to remedy this lack include: facility to pin sets of pages for offline use; a mechanism for detecting that the application is running offline; and events to signal that the user is going offline or returning to online operation. Taken together with the aforementioned client-local storage system, these mechanisms would combine to enable a number of improved and important web experiences.

Embedding and application deployment

For many application developers, putting Mozilla technology inside or underneath their applications has been a bittersweet experience. While they are rightly excited to have the power of the Mozilla platform at their disposal, the state of our embedding interfaces and application-launch facilities have created significant impediments to their productivity, and introduced expensive fragility into their environments. While we wish to see the plight of these developers improve, we do not believe that the "second-class" nature of 3rd party applications can be entirely wiped from our world.

Instead, we will make our own applications use the same interfaces that we recommend for embedders, in both C++ Gecko interaction and the XUL widgetry that is composed above it. For launching applications atop our platform, we will improve and promote XULRunner, and use it to launch Firefox and our other applications. Over time, we seek to drive the number of "embedding bugs", as distinct from "bugs that break our apps", to near-zero by improving alignment and overlap between those domains.