An Introduction

Rick Gessner currently lives in San Diego with his wife and new baby daughter, Megan. He commutes to Mountain View each week.

Rick earned his BS from Arizona State University, and later earned an MBA in technology management. A professional programmer since 1980, Rick has been involved with Object Oriented Programming for quite some time (going back to smalltalk, objective-C, object-pascal), but still claims an affection for Assembly Language. He was the architect of the layout engine for Pages, a DTP system for Nextstep, which he calls "what may have been the coolest OOP desktop publishing system in the world".

He also worked on an Artificial Life / VR project for two years, which he says proves "marketing is often more critical to success than pure technology. The Raptor team has never forgotten this point."

The Genesis of NGLayout

"The genesis of NGLayout originated in the early 1990's when I was responsible for building the layout system for a high-end and object-oriented desktop publishing system," says Rick. "When that company failed, I was fortunate enough to get involved with a few of the smartest guys I've ever known to form DigitalStyle. We moved some of our publishing ideas into the area of web graphics. Netscape caught wind of it, and bought the company so that we could build a next-generation layout engine for their browser.

"The primary engineers in the core layout engine for NGLayout include Peter Linss, Kipp Hickman, Troy Chevalier and myself. We took many of our foundational ideas and fleshed them out into a system that hung together in the Internet space. Since that time, the project has gained the contribution of a lot of incredibly talented engineers/architects, as you can see by examining our table implementation, graphics systems, widgets, and of course our DOM."

According to Rick, NGLayout was built from the ground up using an OOP approach.

"The NGLayout system is deeply steeped in hard-core object design," says Rick. "Design patterns were an important part of our modeling processes. After a few months of meetings (described by team members as 'brain boiling') we emerged with what was the prototypical design for NGLayout."

Rick is still involved in some technology decisions (although he suspects that the guys are just being nice), and is implementing the parsing system. He also directs the efforts of the overall team of (20+) folks, serves "as chief cheerleader" and "works with marketing to get Raptor into the hands of our major partners."

It's important to note that NGLayout is more than a layout system. "NGLayout also includes full level 1 DOM support, a CSS-1 (and some CSS-2) style system, XML support, a cross platform rendering model, view system and widgets," says Rick. We will delve deeper into why NGLayout is ultimately a new paradigm later in this article.

The Goal of NGLayout

NGLayout is designed from the ground up to meet the performance and stability needs of web users and to satisfy content developers by supporting emerging web standards. I asked Rick to list some of the ways in which NGLayout improves upon the current layout system. Here's a quick rundown:

NGLayout is smaller, faster and is more modular and extensible that its predecessor. NGLayout will be available as an embeddable component. We are Open Source -- part of the mozilla.org effort. NGLayout will provide the basis for the most standards compliant browser ever produced by Netscape. NGLayout offers an incredibly good rendering/compositing engine to make our drawing outstanding, with top flight layout processes to make it fast.  NGLayout processes operate incrementally. NGLayout offers DOM level 1 support as well as a full CSS implementation. We can support foreign languages far better, eventually including those that require bidirectional text. We support i18n better -- unicode support is baked in. NGLayout will go beyond web content to provide intrinsic support for Web-UI.

Rick continues, "More importantly, NGLayout will serve as the basis for new capabilities that web-content developers are only beginning to demand. The openness of the architecture (not to mention the source-base) will enable us to bring new technologies to customers far faster than any other browser.

"We view the web as the convergence of networking, multimedia and publishing. Our design model mandates a strong separation of content, style and structure. As such, it allows developers to operate on as much or as little of the underlying data as they need, and in a totally rational/normalized way. We essentially want to enable web-developers to build the kinds of applications that their customers demand quicky and with the greatest flexibility possible."

A New Paradigm

In addition to coding the parsing/rendering/styling engine, there will also be an effort to integrate the layout into a new front-end (FE for short) for the application. [The front-end of an app is the "chrome", or combination of menus, toolbars, and status bars that enclose the layout engine.] I asked Rick to explain some of the issues behind this integration, and why they are not integrating NGLayout into the current front-end schema.

"The new engine is in fact far more than just a drop-in replacement. For one thing, anyone who has looked at Navigator code can see that while it has served its purpose beautifully, it is not modular in a significant way. So dropping a modular layout engine into Navigator would be nearly impossible. (We know because we studied the problem enough, and tried a prototype.) In fact, figuring out how to integrate the new modular systems with the bulk of the navigator codebase was a considerable engineering feat unto itself.

"The FEs make a good case in point. In the existing architecture, the FEs were tightly coupled with back-end processes and were also pretty much aware of threading issues. With FEs in particular, this is not desirable. The model/view/controller paradigm from Smalltalk proved the utility of separating UI from back-end processes, and yet again from the underlying content model(s). This is not the case in the existing architecture. As a result, it has become exceeding difficult to make considerable improvements to these systems without experiencing some code 'fragility'.

"NGLayout uses a clearly separated set of content models (which enables DOM, CSS, XML and editing). The layout processes operate against these models to produced a rendered document. Forwarding that concept, it can be shown that the same types of processes are useful in the area of UI, and that's what we're doing. The new XPFE system that builds upon NGLayout will allow the system to layout the UI using the same simple principles that allows an HTML document to be rendered. Suddenly the lines between content (data models), layout and UI will all be blurred to the benefit of our customers. In essence, the retooling of our FEs is being done to take advantage of powerful new capabilities offered by NGLayout.

"NGLayout is also a far more incremental in its processes than was its predecessor. That means we do a better job of incrementally downloading content, and then incrementally parsing, laying out and rendering that content. But the fundamental networking architecture remains the same."

Standards Compliance

The most important aspect of NGLayout, and the one getting the most attention, is its standards compliance. As Rick mentioned, NGLayout was architected from the ground up to be able to deal with new content and style models easily. I asked Rick to catch us up on the status of NGLayout with regard to various standards now in place.

CSS

"I've heard from folks on the Web that we have already surpassed the other browsers (including Navigator) in our handling of CSS1, although I have not yet proven this to myself. I do know however that as general and extensible as our layout system is, our style system is just as good. It doesn't presume a given style model, and can therefore map existing (or new) style models onto our content models. This gives us the ability to add support for CSSx and other style models very quickly.

"While we have no 'official' CSS2 requirements for version 1.0, our style team has already added support for almost the complete set of CSS2 properties. If we had our choice, we'd love to see a full CSS2 implementation in the first release. In fact, we'd like to invite net developers to 'jump on board' and help us with this endeavor."

XML

"Netscape has already adopted Jim Clark's parser for XML. In addition, the native parsing engine in NGLayout can handle XML, and has classes (currently stubbed) that will ultimately support both well formed and valid XML documents. (In fact, the native parsing engine can be dynamically extended to handle whatever grammar you wish to throw at it.)

"Netscape has made a serious commitment to XML. The NGLayout system already uses two proprietary XML schemas for interprocess purposes (but for the time being they are not exposed to content developers). I expect that our XPFE functionality will also utilized XML to great extent, and that this represents an opportunity for web-content developers and application developers to create new kinds of web-based user experiences."

DOM Level 1

"For starters, our DOM implementation will be W3C compliant. It's our objective to allow content developers to use our tools interoperably with competitive products -- so we've kept ourselves from offering proprietary extensions.

"DOM support in NGLayout is based on a set of 'well-formed' content models. NGlayout maintains and exposes a set of models that are created when each document is loaded. These persistent models are available as first class objects to the DOM. It is essential that these models be normalized so that transactions via the DOM (or any other means) will always result in a coherent document. Therefore, the NGLayout system designers have asserted that these models must be valid -- an assumption that is shared by the DOM and CSS working group specifications. This ensures that operations against the content model will be predictable and repeatable.

"The bindings between Javascript and our DOM are IDL based, making the implementation easier." [IDL, or Interface Description Language, is a mechanism for describing programming interfaces in high-level terms. This allows the programmers to navigate through the troubled waters of cross platform implementations much more smoothly.] Rick continues, "Recently our DOM team connected the DOM interfaces to the style system in just one week (proof of a great modular design). The results are outstanding, and show tremendous promise for content-developers looking for new and cool design features. And of course the fact that we've used XPCOM as the basis for our design gives us far better interoperability and extensibility."

HTML 4.0

"We're working towards supporting the 4.0 specification in our 1.0 release. Keep your fingers crossed!"

NGLayout and the Current Layout Engine

Where does NGLayout stand today? And how long will the current layout engine still be in play? "NGLayout runs nicely on win32 today, offering incremental layout of most HTML elements," Rick states. We have CSS1 and some CSS2 support now, and our DOM level 1 support is starting to come online. Applets and plugins are beginning to work, and printing should come online in November. Security will be present by the beginning of the year or so.

"The Linux version lags by about 1 month, and the Mac by about 2 (though it is catching up).

"Of course since NGLayout is portable, I've also heard that independent Web developers have it running or nearly running on Rhapsody, OS/2, IRIX, and there is even an BeOS port underway."

The issue of the current layout engine still exists. Specifically, there are questions as to how long it will continue to be in play. I asked Rick to clear the air on this issue. "While it's still too early to publicly discuss Netscape's plans, very exciting news has come from mozilla.org. Mozilla recently announced that they have moved off the old source-code base and onto NGLayout. This is especially good news for web developers who can work with a much smaller, more rational system. Mozilla expects this to dramatically increase the leverage that it gets from web developers who were waiting for this kind of bold move."

Concluding Remarks

I thought it would be best to leave you with some remarks from Rick which I believe make very clear the team's commitment to standards and the Mozilla community. Remember, Rick has been down in the code from its beginning - he's not a higher up so totally divorced from the code that his proclamations are utterly worthless. Without further ado:

"The Netscape and NGLayout team want to ensure that the web has a future based on open standards. NGLayout supports our conviction by providing as much compliance with web standards as we can possible provide in this timeframe. But it's also important to recognize that standards mean little if performance is unacceptable. So NGLayout is focusing on these key areas: performance, stability and standards.

"We want to make web development exciting again. The open/extensible architecture of the system will offer both the content developer and the application developer an opportunity to innovate on the net in ways they never could before.

"Please make sure your audience realizes just how serious we are about enlisting their involvement. I've personally spoken with over 100 developers in order to integrate their ideas and code into NGLayout. If NGLayout succeeds, it will be because the web rallies behind this bold initiative and casts their vote by participating.

Netscape engineers are easily the best team I've had the pleasure to work with. The web development community can be part of that great team, and help Netscape change the world again!"