Gecko Changes Everything
Designers and developers should love Netscape's new standards-compliant browser.
By Richard Koman
WebTools
December 23, 1998
After years of tweaking the code that rendered Web pages in its browser, after getting "more useful miles out of those vehicles than anyone rightly expected," according to a key Netscape developer, Netscape has decided to scrap the code in its browser engine and start from scratch.
The result: a browser that
Netscape's decision to start from scratch stemmed from the increasingly painful dance Web-page designers must do to make their sites look good on all browsers and all platforms.
The transition from the 3.0 browsers to 4.0 browsers has been a "nightmare," said one Web developer, and no one could fault users for being unmotivated to download 12-megabyte and larger files that only seem to increase the number of times a day the browser crashes.
Until this fall, it seemed the open source Mozilla browser would deliver more of the same. Netscape was planning on releasing that browser as Communicator 5.0, but with its acquisition by America Online, who knows? While Netscape was winning points for converting to an open source model (in which the source code is published freely and worked on by groups of internal and external developers), the likelihood that the new browser would ship with the same old, standards-flouting layout engine caused developers to cry into their mouse pads.
Now everything has changed.
Why the Switch?
Late in October, Netscape changed course, opting to adopt a new "layout engine" (the code that draws the HTML document on your screen) and jettisoning all the work done to date with the old layout engine. Originally called NGLayout, the new layout engine was officially dubbed Gecko and made publicly available at Cnet's Builder Live conference in early December.
The new engine is orders of magnitude smaller, faster, and more efficient. To prove the point, Netscape was handing out single diskettes containing the compressed Gecko browser.
Why the change? According to Brendan Eich, the Mozilla Project's architecture and technical director and inventor of JavaScript, the change has been needed for a long time. "NG's seeds were sown at the development of JavaScript. When I wrote the JavaScript [language], I wanted something like NG."
He explains the decision to switch in his road map: "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."
In addition, developers who wanted to write programs that hook into the browser found the old engine "less than hospitable," he wrote.
"It's time to stop banging our heads on the old layout and front-end code base. 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 web sites. We have a convincing proof-of-concept for a cross-platform front end (XPFE). Why not use these two new projects in Mozilla, to solve a bunch of longstanding problems?
"All of the following combined to say 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. 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."
Since Gecko is built with a modular architecture, it should be easy for third-party developers to embed these modular components into their applications, says Angus Davis, product manager for Netscape's content platform.
"This is what AOL is doing with ICQ and NeoPlanet is doing with their browser app. The old code base was more monolithic in nature," Davis says.
While AOL hasn't announced specific plans for the Netscape browser, one possible scenario is they would embed browser components into the AOL client, allowing for a more seamless path between AOL and Web content.
Taking the Acid Test
Dynamic HTML is a good example of the problems between the major browsers. The promise was for a highly interactive, object-oriented Web, with drag-and-drop functionality and elements that moved and interacted with each other.
The reality? Two browsers that implement the core underlying standards -- CSS and DOM -- inconsistently and incompatibly. A painful authoring process that involves checking browser identity and conditioning behavior accordingly. The added complexity of making DHTML-aware pages backwards-compatible with older browsers. The frustration of standards-compliant documents that break in the major browsers.
In other words, a real nightmare.
To illustrate the differences, take a look at the "box acid test." (See http://style.verso.com/boxacidtest/.) This page is a CSS document consisting of several boxes with colored backgrounds and containing text and form elements. While the document is complex, it is 100 percent legal CSS and a 100 percent-compliant browser would render it correctly.
This picture is a reference GIF showing the correct rendering of the page.
Now here's what Netscape 4.5 does with the same page.
Now here's what Netscape 4.5 does with the same page.
No wonder developers are frustrated. "I cannot create a page in Dreamweaver -- one simple, elegant little CSSP page -- and have it render correctly in their stupid browser," says Webmonkey designer Anna McMillan.
Fellow Webmonkey Taylor echoes her sentiments: "The browsers have taken the most divergent paths ever. The version 3.0 and version 4.0 browsers differ, the version 4.0 browsers differ between vendors, between platforms. I just feel angry and helpless that the base standards I need to do my job go unsupported."
Since Gecko is supposed to be 100 percent-compliant with the Level 1 standards, let's take a look at how the new layout engine does with the acid test.
We know Mozilla will be a 100 percent-compliant CSS browser.
That's 100 percent perfect. So at least we know Mozilla will be a 100 percent-compliant CSS browser. And that's a great thing for developers.
But what about Internet Explorer?
Microsoft Forced to Follow?
In the Web developers' fantasy world, a rich set of standards are 100 percent supported by all important browsers on all important platforms. With HTML 4, CSS, and the DOM, we have the rich standards. With Mozilla, we'll have one cross-platform browser that supports them completely. But what about Internet Explorer?
While IE 4.0 largely supports the standards, it's not 100 percent-compliant.
"The only win for developers is if both version 5.0 browsers come out and have 100 percent CSS and DOM. That's the only thing developers care about," says Webmonkey's Taylor.
Microsoft hasn't released the final version of IE 5.0 (nor have they committed to 100 percent compliance to the standards), so it's worth running a beta of IE 5.0 through the acid test and see how it does. Note that this is the Win 32 beta (the only platform so far released) and that DHTML support in Mac IE lagged woefully behind the Windows version. Here's how IE 5b2 handled the acid test:
Here's how IE 5b2 handled the acid test
Not as bad as Netscape 4.5, but not right, either. So to borrow a phrase from the election poll takers, if these browsers were released today in their current state of standards compliance, we would have one browser that is 100 percent-compliant (Mozilla) and one that is somewhat less compliant (IE 5.0). Is that good enough?
It may be, because if Mozilla.org succeeds at 100 percent compliance, Microsoft may be forced to play catch-up to avoid losing browser share.
(For specific data on how well the browsers support the CSS1 spec, see Web Review's CSS Leader Board.)
In fact, if they don't do it, you may be able to run a patch to replace IE's layout engine. "Because Microsoft has opened their APIs, we can actually replace their Trident layout engine with NGLayout," says Eich. "A developer named Adam Lock has actually done this patch."
So does that mean developers will draw a line in the sand and write only standards-compliant code, since there is now a browser that can render standards-compliant code?
No, Taylor says. "Supporting both is not a matter of choice. You have to support both. But for users and corporations, one of the big factors in choosing one browser or another should be 100 percent compliance."
Gecko's Guts
Of course, NG doesn't just support the CSS standard. Here's the list of standards that will be 100 percent supported in Netscape 5.0, thanks to the switch to NG.
HTML 4.0
Style Sheets
CSS1
CSS2 (partial support)
DOM
Level 0
Level 1 Core
Level 1 HTML
Level 1 XML
XML 1.0
JavaScript including ECMA-262 compliance
Transfer protocols: HTTP, FTP, Gopher (also File, Resource)
SSL
Unicode
OJI (Open Java Interface)
Image formats
PNG
GIF
JPEG, PJPEG
ART
XBM
Thus, as Taylor says, "Mozilla sets the bar for compliance."
So why couldn't the old layout engine manage this kind of standards support? Eich blames it on its basic architecture. "The old layout engine doesn't save any structure. It just writes the whole document one time." So, if you want to change an element on the page, the whole page is redrawn.
"The new engine saves structure, so you can reformat part of the document. This allows for incremental reflow," Eich says.
So besides standards support, what else should Web authors look for in Mozilla 5.0?
"Look for 2-D persistent graphics that can be resized on the fly, plus alpha channeling" -- the ability to mask or filter an element through a hidden grayscale layer, Eich says. "We want to move the goal posts."
Does AOL "Get It"?
There have been promises of better browsers before, but the problem has always been getting users to upgrade to the latest version with the whizzy new features you want to use. The upgrade cycle from the version 3 to version 4 browsers was the longest yet, says Taylor. So while it's nice to get a standards-compliant browser, does it really change anything? Won't authors still have to support all those bothersome old browsers?
"Looking back at the whole 4.0 experience," says Taylor, "there was not much reason to upgrade. You didn't get anything more. Developers wouldn't lock out 3.0 browsers. If 5.0 comes out and works well as a development platform and things work consistently, there's more incentive to not support the old browsers."
So what will users get by upgrading to 5.0? For one thing, an extremely fast browser. Taylor expects low-end users to be blown away by the speed improvements.
For another thing, says Eich, Mozilla will be an extremely small browser. Gecko fits on a diskette today, but the Mozilla 5.0 browser based on Gecko might be slightly larger or smaller. Thus, the cost of upgrading will be trivial compared with the version 4.0 browsers.
How did they make Gecko so small? What's in the Communicator code that's not in Gecko? "Monolithic architecture, code bloat, general fatness, andcode rot after a few years of development," Davis says.
The seeds of Mozilla 5.0 started back with Netscape's ill-fated "Java-gator" browser, a joint endeavor with Sun Microsystems, which dried up when Sun failed to come through with development money and Netscape grew dissatisfied with Java's performance.
Meanwhile a Norwegian company was making waves with a small, fast browser called Opera. "We moved away from Java because of efficiency problems," says Eich. "We were looking at Opera as what we should be doing. ... Mozilla is concerned about size and performance. People need DOM and CSS support. Opera is our benchmark for speed and size."
And, adds Mozilla team member Mike Shaver, Mozilla may be the last full-fledged "new browser" you may ever need. "We want to get into [Mozilla] a smart update feature that works in the background, gets the code, and loads it on the system. Because of the modular interface, we can script all components, which allows us to incrementally update."
And now the for the question on everybody's lips: What's the future of Mozilla, now that AOL is acquiring Netscape? In an editorial on the Mozilla site, evangelist Jamie Zawinski argues Mozilla was never simply a browser for Netscape, but rather is an open browser development effort.
Zawinksi argues that neither Netscape nor AOL will ever "own" the code. AOL may choose to fund the project, as Netscape has, or not. They may choose to use the open source browser on their service, or not. But in any case, Zawinksi says, the open source browser is not going away.
In a letter to Zawinski published on the Mozilla site, AOL CEO Steve Case emphasized his support for the AOL project. "We're hopeful that our involvement might rally even more support among developers in the open source community. ... We share your view that the agenda of Mozilla is and should be set by those who contribute to it. We will contribute, too -- in part, by maintaining the autonomy of mozilla.org."
While Case stopped short of announcing plans to use and integrate the browser into the AOL service, his words give hope to those who would love to see a standards-compliant browser in the hands of approximately 18 million users.
Richard Koman is a book editor for O'Reilly & Associates. He is a former editor of Web Review and has written two books about Web software.
Copyright 1998