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:

Not only will many bugs and lacks be resolved, the road ahead can better support a full mail client, user-scriptable hooks, and many other clients and proxy-like modules.

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).

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 Project / Gecko Layout Engine

FAQ

Last updated 23 March 1999

In this document:

What is Gecko?
Gecko is Netscape's revolutionary next-generation browser engine based entirely on open Internet standards such as HTML 4.0, CSS 1/2, XML 1.0, and the W3C Document Object Model. Gecko also includes a set of complementary browser components that work alongside the layout engine to form the founding platform of Netscape's next generation Web browser. Gecko is currently under development. Gecko has been known previously by the code names "Raptor"  and "NGLayout"; the new name was chosen following a trademark infringement dispute.

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:

How will Gecko format XML documents?
Gecko will support the use of CSS1 to format XML documents.

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)

How does Gecko help content developers?
Content developers are sick and tired of developing and testing every single web page multiple times in order to support the different, incompatible, proprietary DOMs of browsers from different vendors. They have been demanding that all vendors fully support the W3C DOM and the other standards listed above so that they can (1) have a rich, powerful formatting system and object model at their disposal, and (2) "write once, view anywhere." Gecko's full support of HTML 4.0, CSS1, DOM1, XML, XML+CSS1, and RDF will make Gecko the content platform of choice for content developers worldwide.

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:

Components marked with an asterisk are currently being extracted from the 5.0 codebase and given XPCOM interfaces and haven't yet landed in the Gecko tree.

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