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:
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:
In light of the "open source solution" principle, the widget library used by NGLayout needs to be ported from Motif to GTK+.
NGLayout Project / Gecko Layout Engine
FAQ
Last updated 23 March 1999In this document:
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:
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:How does Gecko help content developers?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:
NGLayout Project
Glossary
Copyright © 1998 The Mozilla Organization