Mozilla Development Roadmap

October 26, 1998

Brendan Eich

Welcome to the Mozilla browser development roadmap. For up-to-the-minute answers to frequently-asked questions, click here.

In my experience, the best maps contain historical notes and sightseeing tips. A software roadmap in particular must keep integrating the present as it passes by, or it soon becomes useless. That kind of map records design decisions and their rationales. More important, such a map reflects unforeseen terrain and unexpected inventions as they emerge, rather than starting from some (unrealistic) fixed architecture and proceeding through mundane implementation.

Brief History

It has been over five months since I posted to mozilla.general my then-current thoughts on the Mozilla browser development schedule. That schedule listed only one large feature, mail/news integration, and put off enumerating the rest until "later, [...] barring a better idea."

Since then, a lot of great work has been done by all mozilla.org developers, fixing warnings and bugs, porting and cleaning up code, improving performance, refining downloadable chrome, setting up the autoconf build system, etc. But the mail/news code from Netscape never arrived. The features most demanded by content developers (incremental layout with reflow, correct CSS, a Level-1 DOM) have been hard to implement on the old codebase. And developers who have wanted to "just add a hook", a la Emacs and its extension languages, have found the old layout and FE code less hospitable than they would like.

Well, now is later, and we do have a better idea or three.

Where We're Going

It's time to stop banging our heads on the old layout and FE codebase. We've pulled more useful miles out of those vehicles than anyone rightly expected. We now have a great new layout engine that can view hundreds of top websites. We have a convincing proof-of-concept for an XPFE. Why not use these two new projects in Mozilla, to solve a bunch of longstanding problems? All of the following combined to say that it is time for the Mozilla browser project to use XPFE and NGLayout:

• the judgment of the module owners;
• the fervent wishes of web content authors; and
• my personal judgment as mozilla.org technical bigshot

Moving to XPFE and NGLayout means moth-balling all of the old-style FEs, and of course mozilla/lib/layout and its friends. Coordinated development will cease right away on the old layout code, XFE, and all of the other FEs.

Note however that most back-end modules carry forward with XPFE and NGLayout; many already work with NGLayout as-is, while some have been #ifdef'ed. While we won't break old layout and FEs intentionally, evolution of all the back-end modules common to old and new layout will tend to rot the old codebase. We've already CVS-tagged the mozilla tree with the label MozillaSourceClassic_19981026_BASE to facilitate mothballing and archaeology (there's also a MozillaSourceClassic_19981026_BRANCH branch tag for retrograde development).

Re-Introduction

This document will serve as a narrative roadmap for mozilla browser development. It won't be a schedule, although schedules should be attempted that refer to the terrain recorded and projected here. It will state rules of the road, or the design principles we'd like to employ, to build on the value of XPFE, NGLayout, and modularity using XPCOM. It will list major items of work. And I'll update it over time to reflect reality.

Nothing (apart from accurate history) in this roadmap should be taken as irrevocable. Although we try to avoid unduly revisiting decisions, we welcome all developer comments and corrections. Let controversy bloom if it needs to. Just give us your evidence and reasons, and we at mozilla.org will correct our course and this map to match the actual terrain.

Design Principles

Here are the browser road rules. Some of these points are concrete design decisions more than highfalutin' principles. But we think they reflect sound ideas (for example, autoconf captures feature dependencies better than our old Unix build system's platform macros and consequent #if defined(linux) || ... tests in the code).

• External development counts more than convenience or ease-of-habit for internal-to-Netscape developers. The Netscape X-heads, for example, have moved all of their mail usage except for I'm-out-sick-today and any truly-proprietary messages to the mozilla.unix newsgroup. Likewise with NGLayout hackers and the mozilla.layout group. So it shall be for all development.
• Fresh mail and news clients will be designed and implemented jointly by Netscape and external developers, using open source methods, and this time with an open source database (which I think is likely to be Berkeley DB). The new mail/news code will use NGLayout for HTML rendering. It shall use as much XPFE-like cross-platform widgetry as it can; it shall use thin-mail techniques akin to Ender and Shack.
• As much as possible, UI structure should be implemented using HTML or XML and the NGLayout engine. Style should be expressed using CSS where doing so makes sense, and doesn't require non-standard extensions to CSS. Structure that can be queried, modified, and superposed from remote sources should probably be RDF, expressed in its XML syntax. Actions should be implemented (or at least, be implementable) via well-defined events and their JavaScript handlers
• Modules will use XP-IDL and XPCOM to specify and query their programmatic interfaces. That way, all modules are scriptable without requiring all interface creators to write repetitive-yet-tricky script-engine glue by hand. Also, parts of the system may be distributed across thread, process, and machine boundaries using automatically generated stubs. This distribution potential is a distant second goal, except where single-threaded code restrictions require us to implement an apartment threading model.
• Any scripting hooks above and beyond the scriptable-C++ entry points that we get by using XP-IDL must be designed and specified using IDL extensions. The crucial principle here is to make all useful parts of the browser easy to script. What's more, events must be easy to "hook" or handle in a flexible way, say using JavaScript. More on this point will be written in the XPCOM-Connect document.
• autoconf will be the one true Unix-hosted build system for the modules you checkout and build en masse to make a browser that runs on Unix. Module owners will have to maintain only their module's Makefile.in and configure.in scripts for Unix, not both of those and gmake Makefiles. (This principle does not apply to NSPR, which is a separately-built prerequisite of the browser; it may be that the Berkeley DB follows NSPR into separately-built prerequisite status, eventually.)
• X-heads believe the time is right to move from Motif to GTK+, the leading fully-open-source X-based UI toolkit. The general principle here, mentioned above in the mail/news paragraph in connection with Berkeley DB, and of course behind autoconf adoption, is that Mozilla must use the best open source solution to solve a well-understood problem.

Major Work Items

Each of the following tasks constitutes a major milestone. This list isn't even partially ordered, but it should be, to express dependencies. It should be topologically sorted and scheduled, too (later). It shall be refined to include sub-tasks and missing items of work. For now, it's a roughly-ordered brain dump of what I think we'll all be doing in the next few months:

• NGLayout completion. See the NGLayout Project Page for detailed to-do lists and schedules.

  In light of the "open source solution" principle, the widget library used by NGLayout needs to be ported from Motif to GTK+.

   

• The old composer/editor was tightly coupled to old layout. NGLayout has a rich DOM API that perhaps (with more event work) could form the basis for the new editor. In any case, Mozilla must have an HTML composer/editor, and it should be embeddable via an OBJECT or TEXTAREA TYPE="text/html" tag.

   

• XPFE design and implementation. There is a very preliminary set of design documents , but they are subject to change and evolution based on the design principles above, and interested developers' input.

   

• Back-end modules such as RDF and JavaScript are more-or-less ready to go, but their interactions, especially their execution model interactions, need analysis. Also, memory consumption and things like garbage collector scheduling require a "whole system" analysis.

   

• Mail/news XPFE and modular back-ends need to be designed and implemented, or in a few cases evolved from existing Mozilla code such as mozilla/lib/libmime.

   

• The XP-IDL compiler and IDL specs for all interfaces must be written, tested, and deployed as part of the build system.

   

• The JavaScript XPCOM-Connect runtime, by which JS can call C++ methods using runtime type information, and convert results to JS types, must be built. The good news is that some of it will resemble LiveConnect. The bad (or good, for hackers who enjoy it) news is that we need some assembly code to implement each platform's Invoke method, where platform is a pair: (cpu instruction set architecture, compiler-and-cpu-determined calling conventions).

   

• Conversion of all Unix builds to autoconf. Currently, NGLayout is built by mozilla/nglayout.mk. If we follow the existing browser build model, it should be built by the Makefile generated from mozilla/Makefile.in and mozilla/configure.in.

   

• For Windows builds, at the least mozilla/nglayout.mak and mozilla/client.mak need to unify under the latter name. But it seems possible to use autoconf even on Win32, along with cygwin32 tools. Perhaps some ATL-like dependency will prevent it, but it should be given a fair shot.

NGLayout Project / Gecko Layout Engine

FAQ

In this document:

• What is Gecko?
• What is the relationship between the mozilla.org "NGLayout Project" and the "Gecko layout engine"?
• What is a layout engine?
• How is a layout engine like Gecko different from a web browser?
• Why are we building a new layout engine?
• How is mozilla.org using Gecko?
• How is Netscape planning use Gecko?
• How can other companies and organizations use Gecko?
• Which open standards does Gecko support, and to what extent does it support them?
• How will Gecko format XML documents?
  •  For XML formatting, why is Gecko supporting CSS instead of XSL in the first release?
• How does Gecko help content developers?
• Are Gecko's APIs based on ActiveX? COM? JavaBeans?
• Are Gecko's APIs compatible with Microsoft's Trident APIs?
• Which platforms does Gecko run on?
• What are the components of Gecko?

What is the relationship between the mozilla.org "NGLayout Project" and the "Gecko layout engine"?
mozilla.org's "NGLayout Project" is creating the "Gecko layout engine." Although the layout engine's name has been changed to Gecko, the project's name has remained "NGLayout Project" for historical reasons.

What is a layout engine?
Basically, a layout engine takes content (such as HTML, XML, image files, applets, and so on) and formatting information (such as Cascading Style Sheets, hard-code HTML tags, etc.) and displays the formatted content on the screen. It "paints" the browser's content area, which is the blank area inside the browser window's "chrome."

Formally, a layout engine defines the placement policy for a document and places content on a page. Gecko's core is a very fast layout engine. Gecko also offers the ability to parse various document types (HTML, XML, CSS, etc), advanced rendering capabilities including compositing and tranforms, and support for embedded JavaScript and applets.

Note: Gecko is so fast and so powerful that it's being used to create the browser's user interface ("chrome") as well. In other words, Gecko will not only be displaying the document's content, but it will also be painting the scroll bars, tool bars, and menus on the screen as well.

How is a layout engine like Gecko different from a Web browser?
Gecko provides the foundation needed to display content on the screen, including a layout engine and a complementary set of browser components. However, Gecko does not package all of these components alongside other interface modules in a coherent, user friendly Web browser application (including menus, tool bars, etc.), such as Netscape Navigator.

mozilla.org will assemble the necessary components into an application called the Mozilla browser, which will be available for free download from mozilla.org. Netscape will release its own version of the browser branded as Netscape Navigator, which will be available for free download from netscape.com.

Third parties such as ISVs and hardware vendors will pick and choose the components they want to use in their applications or hardware devices. Certain browser components are not provided as part of Gecko, such as bookmarks, history, address book, etc. However, the source for all those components is available for free download from mozilla.org.

Why are we building a new layout engine?
The original Mozilla browser, first released as Navigator 1.0, was developed rapidly by a small team that was passionate about creating the next killer app -- and they succeeded wildly. Now that the web has evolved, Netscape has assembed the finest team available to redesign and redevelop the next generation layout engine upon which it will build future products. Gecko enables a pioneering new class of dynamic content that is more interactive and offers greater presentation control to Web developers, using open and recommended Internet standards instead of proprietary APIs. You are encouraged to join this team by getting involved.

How is mozilla.org using Gecko?
mozilla.org will assemble the Gecko layout engine and other browser components into the Mozilla browser application.

How is Netscape planning to use Gecko?
Gecko lies at the heart of Communicator, powering all of the individual components including Navigator and Messenger. Gecko technologies will also power the display of Netcenter, the Web's leading portal site, speedily delivering more exciting content and services. Gecko's architecture will serve Netscape well into the future, enabling faster time to market, more innovation, less costly development, easier distribution and updating, and better cross platform support.

How can other companies and organizations use Gecko?
Because Gecko is small, lightweight, and open source, other companies and organizations can easily reuse it. Many hardware vendors are creating devices with network access and wish to include web browsing functionality. Likewise, many software developers want to include Web browsing capability in their applications, but don't want to independently develop browser software. These developers can pick and choose the browser components they want from among those that Gecko offers, and package these components alongside their own within their finished products.

Which open standards does Gecko support, and to what extent does it support them?
The first release of Gecko will support the following recommended open Internet standards completely (100%) unless specifically noted:

• HTML 4.0 - complete support except for bidirectional text layout, which is only used in Hebrew and Arabic
• Style Sheets
  • CSS 1 - complete support
  • CSS 2 - partial support is expected and has already been built into Gecko, but no specific level of support has been committed
• DOM
  • Level 0
  • Level 1 Core
  • Level 1 HTML
  • Level 1 XML
• XML 1.0
• JavaScript 1.5, including ECMA-262 (ECMAscript) compliance
• Transfer protocols: HTTP, FTP, Gopher
• SSL
• Unicode
• OJI (Open Java Interface)
• Image formats
  • PNG
  • GIF
  • JPEG, PJPEG
  • XBM

For XML formatting, why is Gecko supporting CSS rather than XSL in the first release?

Simple: CSS1 is a finished, fully adopted, and mature two-year-old standard; XSL isn't done yet. As Tim Bray, the coeditor of the XML standard, has written:

"Microsoft's XSL efforts are very impressive, but (readers will pardon us being something of a broken record on this subject) XSL is in the future. We are convinced that from the point of view of the largest number of users, the most important things that Microsoft could do in IE 5 would be:

1.Ensure interoperability of XML and stylesheets with other browsers, and
2.Build in conformance to existing, stable, well-understood standards such as CSS 1.0.

Innovation, of course, is fine and necessary, and we salute Microsoft's leadership in this area. But innovation needs to be built on a foundation of interoperability and playing by existing well-understood rules." He further adds that "It seems obvious to me that for anyone who wants to deploy XML in production mode right now, XML + CSS is the way to go …" ("Microsoft Outlines XML Support in IE5 Beta 2" at
http://www.xml.com/xml/pub/98/10/ie5-2.html)

Are Gecko's APIs based on ActiveX? COM? JavaBeans?
Gecko is reusable on all platforms thanks to XPCOM, a subset of COM that works across platforms. COM, developed by Digital and later adopted by Microsoft, is the de facto standard for modular interfaces on Windows platforms. Additionally, on the Windows platform, Gecko's XPCOM interfaces are wrapped in an ActiveX control that VB developers can utilize (ActiveX wrappers are not available on other platforms because ActiveX is a Windows-only technology). A JavaBean wrapper is not currently under development, but there is nothing in Gecko's architecture that precludes such development in the future. Source code and documentation for these interfaces are available through mozilla.org.

Are Gecko's APIs compatible with Microsoft's Trident APIs?
Gecko's XPCOM interfaces are different than Microsoft's. The most important differences between the two models involve reflection of the Document Object Model (DOM) in the interfaces. Microsoft's Trident interfaces reflect the DOM in a proprietary API, whereas Gecko exposes the DOM according to the W3C's recommended standard. Other incompatibilities exist. Adam Lock is creating a partial compatibility layer that may enable developers to easily migrate from Microsoft's engine to the NGLayout engine.

Which platforms does Gecko run on?
Gecko runs today on Win32 (Windows 95, Windows 98, Windows NT 4, Windows NT 5), PowerMac, and Linux. OEMs and contributors from the Net participating in mozilla.org will port Gecko to other platforms. Such porting efforts are underway for Solaris, Irix, OS/2, and BeOS, among others.

What are the components of Gecko?
Gecko includes the following components:

• Document parser (handles HTML, XML, and arbitrary document types)
• Layout engine with content model
• Style system (handles CSS, etc.)
• JavaScript runtime
• Image rendering library
• Networking library
• Platform-specific graphics rendering and widget sets for Win32, X, and Mac
• User preferences library
• Navigator plug-in interface
• Open Java Interface (OJI), with Sun Java 1.2 JVM
• RDF hypertree back end
• Font library *
• Security library *
• Cache management system *

NGLayout Project

Glossary

CSS

Cascading Style Sheets: Standard for defining presentation in Web documents. NGLayout supports CSS1 and most of CSS2. Read the documentation for our style system.

 

BAM

The Netscape internal code-name for our code modularization effort. It stands for "Born Again Modularization." It hinges upon XPCOM.

 

CCP

Cut, Copy and Paste (clipboard operations)

 

CVS

The preferred method for obtaining NGLayout source code and staying in synch with the development effort. See our CVS page for more info.

 

DND

Drag and drop

 

DOM

Document Object Model - the heart of Dynamic HTML. See our DOM technical documentation for more details.

 

DTD

Document Type Definition - specifies a set of elements, their relationships and the tag set to mark the document. A good introduction to SGML concepts can be found here.

 

HTML

Hypertext Markup Language - NGLayout implements HTML 4.0; see the W3C's HTML site for more info

 

libfont

Font library

 

imglib

Image library

 

JS

JavaScript

 

netlib

Networking library

 

NGLayout

Next Generation Layout Engine - see our home page for more info

 

Raptor

Former code-name for NGLayout. We were asked to stop using it in public due to trademark problems. So don't use it :-)

 

RDF

Resource Description Framework - see our RDF technical documentation for more info

 

UI

User Interface

 

Widget

Widgets are buttons, drop-downs, input fields, etc. Needed for form elements.

 

WIP

Work in Progress

 

XIF

XML Interchange Format - used internally by NGLayout for all I/O to clipboard, etc.

 

XML

Extensible Markup Language - see the W3C's XML site for more info

 

XPCOM

Cross Platform Component Object Model - see our docs on how to modularize your code for more info

Copyright © 1998 The Mozilla Organization