summaryrefslogtreecommitdiffstats
path: root/layout/doc/obsolete
diff options
context:
space:
mode:
Diffstat (limited to 'layout/doc/obsolete')
-rw-r--r--layout/doc/obsolete/block.html209
-rw-r--r--layout/doc/obsolete/layout-internals.html101
-rw-r--r--layout/doc/obsolete/layout.css124
-rw-r--r--layout/doc/obsolete/layout.xml279
-rw-r--r--layout/doc/obsolete/line-layout.html118
-rw-r--r--layout/doc/obsolete/nav4-html.html902
6 files changed, 1733 insertions, 0 deletions
diff --git a/layout/doc/obsolete/block.html b/layout/doc/obsolete/block.html
new file mode 100644
index 000000000..255b84cd6
--- /dev/null
+++ b/layout/doc/obsolete/block.html
@@ -0,0 +1,209 @@
+<!-- This Source Code Form is subject to the terms of the Mozilla Public
+ - License, v. 2.0. If a copy of the MPL was not distributed with this
+ - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
+
+<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.61 [en] (X11; I; Linux 2.2.5-22 i686) [Netscape]">
+</head>
+<body>
+
+<h1>
+<u>Block Layout</u></h1>
+This document attempts to describe how "block" layout works in the mozilla
+layout engine.
+<p><tt>nsBlockFrame</tt> implements layout behavior that conforms to the
+CSS "display:block" and "display: list-item" layout. It has several responsibilities:
+<ol>
+<li>
+&nbsp;Line layout. The block is responsible for flowing inline elements
+into "lines" and applying all of the css behavior as one might expect,
+including line-height, vertical-align, relative positioning, etc.</li>
+
+<li>
+Float management. The block is responsible for the reflow and placement
+of floating elements.</li>
+
+<li>
+Child block management. Blocks can contain inline elements and block elements.
+Hence, blocks are responsible for reflowing child blocks. The majority
+of that logic has been split out into nsBlockReflowContext, but a fair
+amount remains here.</li>
+
+<li>
+Supporting table reflow. The block has to carefully compute the "max-element-size"
+information needed by tables. Hence, any time changes are made here one
+should always run the table regression tests because the odds are you broke
+one of them!</li>
+</ol>
+
+<h3>
+<u>The Big Picture for Block Reflow</u></h3>
+The block frame uses a list of nsLineBox's to keep track of each "line"
+of frames it manages. There are two types of lines:
+<blockquote>"inline" lines which contain only inline elements
+<br>"block" lines which contain exactly one block element</blockquote>
+Each line has a "dirty" bit which indicates that it needs reflow. Reflow
+consists of identifying which lines need to be marked dirty and then reflowing
+all lines. For lines which are "clean" the reflow logic will endeavor to
+recover the state of reflow <i>as if the line had been reflowed</i>. This
+saves time and allows for a faster incremental reflow. For lines which
+are dirty, the line is reflowed appropriately.
+<p>The only special thing about incremental reflow command handling is
+that it marks lines dirty before proceeding, and keeps track of the child
+frame that is the next frame on the reflow command path.
+<p>Here is a list of the various classes involved in block layout:
+<p><b>nsBlockFrame</b>
+<blockquote>The primary culprit.</blockquote>
+<b>nsBlockReflowState</b>
+<blockquote>This helper class is used to augment the nsHTMLReflowState
+with other information needed by the block reflow logic during reflow.
+It is a temporary object that is designed to live on the processor stack
+and contains "running" state used by the blocks reflow logic.</blockquote>
+<b>nsBlockBandData</b>
+<blockquote>Another helper class that wraps up management of a space manager
+(nsISpaceManager, nsSpaceManager) and nsBandData. It also assists in management
+of floating elements. While nsSpaceManager is policy free, nsBlockBandData
+provides specific HTML and CSS policy.</blockquote>
+<b>nsBlockReflowContext</b>
+<blockquote>A helper class that encapsulates the logic needed to reflow
+a child block frame. This is used by the block code reflow a child block
+and to reflow floating elements (which are to be treated as blocks according
+to the CSS2 spec).</blockquote>
+<b>nsLineBox</b>
+<blockquote>A data class used to store line information for the block frame
+code. Each line has a list of children (though the frames are linked together
+across lines to maintain the sibling list for nsIFrame::FirstChild) and
+some other state used to assist in incremental reflow.</blockquote>
+<b>nsLineLayout</b>
+<blockquote>This class is the line layout engine. Its a passive entity
+in the sense that its the responsibility of the block/inline code to use
+the class (this is done so that the line layout engine doesn't have to
+manage child frame lists so that both nsBlockFrame and nsInlineFrame can
+use the class).</blockquote>
+<b>nsTextRun</b>
+<blockquote>This is a data class used to store text run information. Text
+runs are <i>logically</i> contiguous runs of text (they may or may not
+be structurally contiguous). The block frame stores a pointer to a list
+of nsTextRun's and during line layout provides the list to the nsLineLayout
+engine so that when text is reflowed the text layout code (nsTextFrame)
+can find related text to properly handle word breaking.</blockquote>
+
+<h3>
+<u>Frame construction methods</u></h3>
+When the blocks child list is modified (AppendFrames, InsertFrames, RemoveFrame)
+the block code updates its nsLineBox list. Since each nsLineBox is typed
+(some are marked "inline" and some are marked "block"), the update logic
+maintains the invariant of "one block frame per block line".
+<p>When structural changes are made to the blocks children (append/insert/remove)
+the block code updates the line's and then marks the affected lines "dirty"
+(each nsLineBox has a dirty bit). After the structural changes are finished
+then the block will generate an incremental reflow command of type "ReflowDirty".
+<h3>
+<u>Line Layout</u></h3>
+Line layout consists of the placement of inline elements on a line until
+there is no more room on the line. At that point the line is "broken" and
+continued on the next line. This process continues until all inline elements
+have been exhausted. The block code maintains a list of "nsLineBox"'s to
+facilitate this. These are used instead of frames because they use less
+memory and because it allows the block to directly control their behavior.
+<p>The helper class nsLineLayout provides the majority of the line layout
+behavior needed by the block.
+<p>The block does keep "text-run" information around for the nsLineLayout
+logic to use during reflow. Text runs keep track of logically adjacent
+pieces of text within a block. This information is essential for properly
+computing line and word breaking. Why? Well, because in html you can write
+something like this:
+<p>&nbsp; &lt;p>I &lt;b>W&lt;/b>as thinking one day&lt;/p>
+<p>Notice that the word "Was" is composed of two pieces of text, and that
+they do <i>not</i> have the same parent (content or frame). To properly
+reflow this and not break the word prematurely after the "W", the text-run
+information is used by the text frame code to "look ahead" and prevent
+premature breaking.
+<p>Lines also keep track of the type of "break" that occurred on the line.
+This is used, for example, to support html's "&lt;br clear=left>" behavior.
+<h3>
+<u>Float Management</u></h3>
+Since child block elements are containing blocks for floats, the only
+place where a block frame will see a float is as part of an inline line.
+Consequently, the nsLineBox will only keep track of floats on inline
+lines (saving storage for block lines).
+<p>The nsLineLayout class and the block frame cooperate in the management
+of floats. Since the frame construction code leaves a "placeholder" frame
+in-flow where the float was found, when nsLineLayout reflows a placeholder
+frame it knows to inform the block about it. That triggers the blocks "AddFloat"
+logic which then determines where the float should be placed (on the
+current line or below the current line).
+<p>The block frame uses the space manager to manage the effects of floats,
+namely the consumption of available space. For example, for a left aligned
+floating element, the inline elements must be placed to the right of the
+float. To simplify this process, the spacemanager is used to keep track
+of available and busy space. Floats when placed mark space as busy and
+the spacemanager will them compute the available space. Most of this logic
+is handled by the nsBlockReflowState which uses a helper class, nsBlockBandData,
+in concert with the space manager, to do the available space computations.
+<h3>
+<u>Child Block Placement</u></h3>
+Child block reflow is done primarily by using the nsBlockReflowContext
+code. However, a key detail worth mentioning here is how margins are handled.
+When the nsHTMLReflowState was created, we placed into it the logic for
+computing margins, border and padding (among other things). Unfortunately,
+given the css rules for sibling and generational margin collapsing, the
+nsHTMLReflowState is unable to properly compute top and bottom margins.
+Hence, the block frame and the nsBlockReflowContext code perform that function.
+At the time that the nsBlockReflowContext was designed and implemented
+we thought that it could compute the top-margin itself and then proceed
+to place the child block element. However, that turned out to be wrong
+(oh well) because the correct available space isn't known until <i>after</i>
+the top margin is computed. Hence, there is some unfortunate duplication
+of reflow state calculations present in the block frame code.
+<h3>
+<u>Bullets</u></h3>
+Another type of block frame is the "display: list-item". List-items use
+nsBulletFrame's to manage bullet reflow. However, the block is responsible
+for bullet placement. In most situations, the nsLineLayout class is used
+to do the placement. However, if the first effective child of the block
+is another block, then the block has to do the placement itself.
+<h3>
+<u>Blank lines</u></h3>
+Because our content model contains as much of the original source documents
+content as possible, we end up with a lot of white space that ends up being
+compressed into nothingness. This white space ends up impacting this logic
+in several ways. For example:
+<p>&nbsp; &lt;div>
+<br>&nbsp;&nbsp; &lt;p>abc&lt;/p>
+<br>&nbsp;&nbsp; &lt;p>def&lt;/p>
+<br>&nbsp; &lt;/div>
+<p>In the content model for the above html, there is white space between
+the various block elements (some after the &lt;div>, some after the first
+&lt;/p>, again after the second &lt;/p>).
+<p>For css margin collapsing to work properly, each of those instances
+of white space has to behave as if they didn't exist. Consequently, there
+is special logic in the inline line reflow code, and in the nsBlockReflowContext
+code and in the GetTopBlockChild method, to basically ignore such lines.
+<h3>
+<u>First-letter style</u></h3>
+The block contributes, in a small way, to first-letter style reflow. The
+frame construction code is responsible for creating the list of child frames
+for all frames, including the block. It manages the creation of letter-frames,
+where appropriate, so that all the block has to do is reflow them almost
+normally like other inline frames.
+<p>There are two things different that the block does:
+<p>It is responsible for calling nsLineLayout::SetFirstLetterStyleOK
+<br>It is responsible for continuing to place frames on a line, even after
+a frame has said "it can't fit". Normally during inline reflow, if a frame
+comes back and says it can't fit, the block will end the line, push all
+remaining frames to the next line and pick up the reflow from there after
+making sure the frame that didn't fit is continued. For letter-frames,
+this would result in the first-letter being on one line with the remaining
+text on subsequent lines. Hence, the block code handles this special case.
+<br>&nbsp;
+<h3>
+<u>First-line style</u></h3>
+First-line is handled entirely by the frame construction code.
+<br>&nbsp;
+<br>&nbsp;
+</body>
+</html>
diff --git a/layout/doc/obsolete/layout-internals.html b/layout/doc/obsolete/layout-internals.html
new file mode 100644
index 000000000..916f943c3
--- /dev/null
+++ b/layout/doc/obsolete/layout-internals.html
@@ -0,0 +1,101 @@
+<!-- This Source Code Form is subject to the terms of the Mozilla Public
+ - License, v. 2.0. If a copy of the MPL was not distributed with this
+ - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
+
+<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="Author" content="Nisheeth Ranjan">
+ <meta name="GENERATOR" content="Mozilla/4.5 [en]C-NSCP (WinNT; U) [Netscape]">
+ <title>HTML Layout Internals</title>
+</head>
+<body>
+
+<h1>
+HTML Layout Internals</h1>
+
+<h2>
+Big picture</h2>
+An HTML document comes in from netlib into the HTML parser.&nbsp; The parser
+creates parser nodes and feeds them to the content sink.&nbsp; The content
+sink constructs a content model that represents the hierarchical structure
+of the document.&nbsp; As different sub-trees in the content model are
+fully available, the stylesheet processor iterates over them and creates
+the corresponding frame hierarchy.&nbsp; The frames recursively layout
+and render themselves.
+<p>The part that we are going to drill down into is the code in the block
+and inline frame classes.&nbsp; Block and inline are the two primary display
+types specified in CSS and are used in the layout of most of the HTML tags.&nbsp;
+The table related tags have their own display types like "table-cell",
+"table-row", etc. and their implementation is a separate topic in itself.
+<h2>
+Block and inline code</h2>
+The main classes involved in the layout of HTML documents are nsBlockFrame
+and nsInlineFrame, both of which inherit from nsContainerFrame (why?).&nbsp;
+These classes are persistent across reflows and are organized in a hierarchy
+to constitute the frame model of the Gecko system.&nbsp; The frame model
+is derived by applying style and presentation semantics to the content
+model.&nbsp; Each frame in the frame model has a one to one correspondence
+with a rectangular region on the presentation context (screen, printer,
+etc.) and contains the formatting information needed to render that rectangle.&nbsp;
+The block and inline frame classes implement the nsIFrame and nsIHTMLReflow
+interfaces.&nbsp; The nsIFrame interface contains methods for managing
+child frames and linkage with sibling frames, accessing the style context
+associated with the frame, painting the frame, and handling events that
+are passed in from the widget hierarchy.&nbsp; The nsIHTMLReflow interface
+inherits from the nsIReflow interface and adds methods related to word
+breaking and whitespace querying.&nbsp; The nsIReflow interface defines
+the Reflow() method that initiates the reflow process along with the
+DidReflow() method that get calledafter the reflow process.&nbsp;
+nsReflowState and nsReflowMetrics are parameters to
+the templatized nsIReflow interface: the former is used to hold state during
+reflow of a frame and the latter is used to return the frame's desired
+size and alignment to the parent frame during the reflow process.
+<p>nsBlockReflowContext and nsBlockReflowState both hold state information
+during the reflow process.&nbsp; nsBlockReflowContext encapsulates the
+state and algorithm for reflowing child block frames.&nbsp; nsBlockReflowState
+contains state and methods used by a block frame to reflow itself.&nbsp;
+Both these classes are instantiated once per block frame.
+<p>The nsLineLayout class is the engine used by the block and inline frame
+classes to layout themselves on a line.&nbsp; Frames get passed in to the
+nsLineLayout class via the BeginSpan() and EndSpan() methods.&nbsp; Each
+span represents a run of frames with the same style data (???).&nbsp; Other
+methods exist on the nsLineLayout class to position and size the frames
+on the current line.
+<p>nsBlockBandData is the class used to manage the processing of the space-manager
+(nsSpaceManager) band data.&nbsp; It provides HTML/CSS specific semantics
+on top of the general space management facilities provided by nsSpaceManager.
+<p>nsSpaceManager is a class that is told about regions that reserve space
+and exposes methods to query for available space in a given band.
+<p>The nsLineBox class represents a horizontal line of frames and is singly
+linked to the next line box in the document.&nbsp; It is basically a container
+of a frame list that share the property of being on the same line in the
+formatted output of the document.
+<p>The nsTextRun class holds on to a list of frames containing pieces of
+text that form a logical text run.&nbsp; This is needed because a single
+text run can occur on leaves at many levels of the document's content tree.&nbsp;
+This class gives the text layout process an efficient way to get access
+to text runs and, so, determine where word breaks should occur.
+<h2>
+Questions</h2>
+What are anonymous blocks (nsBlockFrame.h)?
+<br>What is the difference between a span and a band (nsLineLayout)?
+<br>Why do nsBlockFrame and nsInlineFrame both inherit from nsContainerFrame?
+<h2>
+To Do</h2>
+
+<ol>
+<li>
+Provide more information about methods and state of each of the classes
+above.</li>
+
+<li>
+Give a description of how the above classes interact with each other as
+a simple HTML document is laid out.&nbsp; Then, add in different features
+to the HTML that exercise different areas of the code, like floats, anonymous
+blocks, etc.</li>
+</ol>
+
+</body>
+</html>
diff --git a/layout/doc/obsolete/layout.css b/layout/doc/obsolete/layout.css
new file mode 100644
index 000000000..854ab6c86
--- /dev/null
+++ b/layout/doc/obsolete/layout.css
@@ -0,0 +1,124 @@
+/* This Source Code Form is subject to the terms of the Mozilla Public
+ * License, v. 2.0. If a copy of the MPL was not distributed with this
+ * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
+
+@namespace xlink url("http://www.w3.org/1999/xlink");
+
+Documentation {
+ display: block;
+ font-family: Verdana, sans-serif;
+ font-size: 11pt;
+ margin: 8px;
+}
+Author {
+ display: block;
+ font-size: 90%;
+}
+Author:before {
+ content: "Author: ";
+ font-weight: bold;
+}
+UpdateDate {
+ display: block;
+ font-size: 90%;
+}
+UpdateDate:before {
+ content: "Updated: ";
+ font-weight: bold;
+}
+Title {
+ display: block;
+ font-size: 250%;
+ font-weight: bold;
+ letter-spacing: -1.25pt;
+ margin-top: 0;
+ margin-bottom: .5em;
+}
+SectionHeading {
+ display: block;
+ font-size: 125%;
+ font-weight: bold;
+ margin-top: 2em;
+ margin-bottom: .5em;
+}
+Body {
+ display: block;
+ margin-top: 1em;
+ margin-bottom: .5em;
+}
+SectionHeading + Body { /* body after section heading */
+ margin-top: 0;
+}
+Components {
+ display: block;
+ margin-top: 1em;
+ margin-left: .5in;
+ border: dotted 1px black;
+}
+:link:hover {
+ background-color: blue;
+ color: white;
+ cursor: pointer;
+}
+
+/* workaround for above rule not working */
+*[xlink|type] {
+ cursor: pointer;
+}
+
+/* workaround for above rule not working */
+*[xlink|show="replace"] {
+ cursor: pointer;
+}
+
+Term {
+ display: block;
+ font-weight: bold;
+ background-color: lightyellow;
+ padding-left: .5em;
+}
+Definition {
+ display: block;
+ margin-left: 40px;
+}
+Interfaces, Characteristics, Items, Categories {
+ display: block;
+ margin-left: 40px;
+ list-style-position: outside;
+ list-style-type: disc;
+}
+Purposes {
+ display: block;
+ margin-left: 40px;
+ list-style-position: outside;
+ list-style-type: decimal;
+ counter-reset: -html-counter 0;
+}
+Interface, Characteristic, Purpose, Item, Category {
+ display: list-item;
+}
+RunIn {
+ display: inline;
+ font-weight: bold;
+}
+Note {
+ width: 2in;
+ height: auto;
+ float: right;
+ font-size: 90%;
+ margin-left: 1em;
+ margin-right: .5em;
+ border-top: solid 2px black;
+ border-bottom: solid 1px black;
+ padding: .5em 0;
+}
+Note:before {
+ content: "Note";
+ font-weight: bold;
+ display: inline;
+ background-color: black;
+ color: white;
+ margin-right: .25em;
+ padding: .5em .25em 0 .25em;
+}
+
diff --git a/layout/doc/obsolete/layout.xml b/layout/doc/obsolete/layout.xml
new file mode 100644
index 000000000..9e4774aef
--- /dev/null
+++ b/layout/doc/obsolete/layout.xml
@@ -0,0 +1,279 @@
+<?xml version="1.0"?>
+<!-- This Source Code Form is subject to the terms of the Mozilla Public
+ - License, v. 2.0. If a copy of the MPL was not distributed with this
+ - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
+
+<?xml-stylesheet href="layout.css" type="text/css"?>
+<!DOCTYPE Documentation>
+
+<Documentation xmlns:html="http://www.w3.org/1999/xhtml"
+ xmlns:xlink="http://www.w3.org/1999/xlink">
+
+<Title>Gecko Layout Engine</Title>
+<Author xlink:type="simple" xlink:show="new" xlink:href="mailto:troy@netscape.com">Troy Chevalier</Author>
+<UpdateDate>8 August 1999</UpdateDate>
+
+<SectionHeading>Overview</SectionHeading>
+<Body>Gecko is Mozilla's new layout engine. It is based on the HTML4, CSS1, XML 1.0,
+and DOM Internet standards, and it is built using a modular XPCOM-based
+architecture.</Body>
+
+<Body>When we talk about layout, we're referring to the formatting process that applies
+presentation styles to a source document. The formatting process is controlled
+by the style specification.</Body>
+
+<SectionHeading>Components</SectionHeading>
+<Body>Here are a list of components and terms that will be referenced by this document.</Body>
+
+<Components>
+<Term>Parser</Term>
+<Definition>Either the <A xlink:type="simple" xlink:show="replace" xlink:href="http://www.mozilla.org/newlayout/doc/parser.html">HTML</A>
+or XML parser. Processes the document and makes calls to the content sink.</Definition>
+
+<Term>Content sink</Term>
+<Definition>Called by the parser. Responsible for building the content model.</Definition>
+
+<Term><A xlink:type="simple" xlink:show="replace" xlink:href="http://www.mozilla.org/newlayout/doc/contentmodel.html">Content model</A></Term>
+<Definition>Consists of document object and a tree of content objects. Changes to the
+content model result in modifications of the frame model.</Definition>
+
+<Term>Frame model</Term>
+<Definition><A xlink:type="simple" xlink:show="replace" xlink:href="#Frames">Frames</A> are formatting
+objects. Each frame defines a particular set of formatting characteristics.</Definition>
+
+<Term><A xlink:type="simple" xlink:show="replace" xlink:href="#Reflow">Reflow</A></Term>
+<Definition>The formatting process. Reflow of the frame model defines the visual appearance
+of the formatted document.</Definition>
+
+<Term><A xlink:type="simple" xlink:show="replace" xlink:href="#FrameConstruction">Frame construction</A></Term>
+<Definition>Initial creation and updating of the frame model in response to changes to the
+content model and changes to the style data.</Definition>
+
+<Term><A xlink:type="simple" xlink:show="replace" xlink:href="http://www.mozilla.org/newlayout/doc/style.html">Style system</A></Term>
+<Definition>Provide the mapping and management of style data onto document content in a given
+presentation. Major components are style set, style sheets, style sheet and
+rules, style context, and style sheet loader.</Definition>
+
+<Term>Presentation shell</Term>
+<Definition>Controlling point for managing the presentation of a document.</Definition>
+
+<Term><A xlink:type="simple" xlink:show="replace" xlink:href="http://www.mozilla.org/newlayout/doc/viewsystem.html">View system</A></Term>
+<Definition>Consists of a view manager and view objects arranged in a tree hierarchy.
+Views support overlapped positioning, z-order sorting, and opacity levels.</Definition>
+</Components>
+
+<SectionHeading>Document Loading</SectionHeading>
+<Body>The basic flow of control is as follows: as the parser encounters tokens it notifies
+the content sink that a new node (or child node) is encountered. The content sink
+creates the appropriate type content object and inserts it into the content model.</Body>
+
+<Body>Whenever the content model changes the document's observers are notified. The presentation
+shell is one of the document observers. The presentation shell forwards the document
+change notification to the style set object</Body>
+
+<Body>The style set passes the notification to the frame construction code, the
+frame construction code creates new frames and inserts them into the frame model. The
+document is reflowed, and the formatted changes are displayed.
+</Body>
+
+<Body>
+The actual interfaces involved are:
+<Interfaces>
+<Interface>nsIDocument</Interface>
+<Interface>nsIDocumentObserver</Interface>
+<Interface>nsIPresShell</Interface>
+<Interface>nsIStyleSet</Interface>
+<Interface>nsIStyleFrameConstruction</Interface>
+<Interface>nsIFrame</Interface>
+</Interfaces>
+</Body>
+
+<Body>All of the interface files are located in the mozilla/layout/base/public
+directory.</Body>
+
+<SectionHeading>Object Lifetimes</SectionHeading>
+<Body>Gecko supports multiple views of the same document. This means you can print the
+same document that you're viewing on the screen, and there's only one content
+model. Because there's just a single content model, each of the content objects
+is referenced counted. The document holds a reference to the root content object,
+and each content node holds a reference to its child content nodes.</Body>
+
+<Body>Each view of the document has a separate presentation shell, style manager,
+style set, and frame hierarchy. The presentation shell is the controlling point for
+the presentation of a document, and it holds a reference to the document object.</Body>
+
+<Body>Frames and views are not referenced counted. The lifetime of the frame hierarchy
+is bounded by the lifetime of the presentation shell which owns the frames. The
+lifetime of the view hierarchy is bounded by the lifetime of the view manager
+that owns the views.</Body>
+
+<SectionHeading><html:a name="Frames">Frames</html:a></SectionHeading>
+<Body>Each frame defines a particular set of formatting characteristics. Frames have
+the opportunity to:
+<Characteristics>
+<Characteristic>reflow (format) their child frames</Characteristic>
+<Characteristic>render their appearance</Characteristic>
+<Characteristic>handle mouse and keyboard events</Characteristic>
+<Characteristic>display a cursor</Characteristic>
+<Characteristic>have an associated view object</Characteristic>
+</Characteristics>
+</Body>
+
+<Body>Frames can have multiple child lists, the default unnamed child list
+(referred to as the principal child list) and additional named child lists.
+There is an ordering of frames within a child list, but no ordering
+between frames in different child lists of the same parent frame.</Body>
+
+<Body>The principal child list contains the flowed children, and the additional
+child lists are for out-of-flow frames like floated elements and absolutely
+positioned elements.</Body>
+
+<Body>Child frames are linked together in a singly linked list. Each frame
+defines its own local coordinate space. Frame bounding rects are in twips,
+and the origin is relative to the upper-left corner of its parent frame.
+The bounding rect includes the content area, borders, and padding.</Body>
+
+<SectionHeading><html:a name="FrameConstruction">Frame Construction</html:a></SectionHeading>
+<Body>The frame construction process begins with a notification that content
+has been added or removed or that style has changed.</Body>
+
+<Body>The first step is to resolve style information for the content element.
+This process creates a style context that is stored in the frame (see
+nsIStyleContext).</Body>
+
+<Body>Once style is resolved construction rules are used to decide the type of
+frame to create. First we look at the element's tag and special case some
+things like IMG elements. If we don't create a frame that way, then we use
+the 'display' property to dictate what type of frame to create. Typically
+it's a block or inline frame.</Body>
+
+<Body>For a 'display' value of 'none' no frame is created. For elements that are
+out of the flow (for example, a floated element or an absolutely positioned
+element), a placeholder frame is also created. The placeholder frame is inserted
+into the flow exactly where the out-of-flow frame would have been inserted.
+The out-of-flow frame is then inserted as a child of its containing block in
+one of the additional child lists. Floated frames are inserted into the
+"Float-list" and absolutely positioned frames are inserted into the
+"Absolute-list".</Body>
+
+<SectionHeading>Frame Manager</SectionHeading>
+<Body>The frame manager is owned by the presentation shell and used by both the
+presentation shell and the frame construction code. It serves two main
+purposes:
+<Purposes>
+<Purpose>provides a service for mapping from content object to frame and from out-of-flow
+frame to placeholder frame</Purpose>
+<Purpose>coordinates structural modifications to the frame model</Purpose>
+</Purposes>
+</Body>
+
+<Body>In many places in the frame code we need to find the frame associated with
+a particular content object. In order to quickly implement this operation we
+maintain a mapping from content objects to frames. The frame construction adds
+and removes entries from the map as frames are created and destroyed.</Body>
+
+<Body>When creating new frames and removing existing frames, the frame construction
+code doesn't directly modify the frame hierarchy. Instead if informs the frame
+manager and has it coordinate the request. If the frame model lock is available,
+the change is processed immediately; otherwise, the request is queued and
+processed later.</Body>
+
+<Body>The frame manager also coordinates processing of replaced elements that can't
+be rendered (for example, an IMG or OBJECT element), and it allows client to
+register to be notified when a particular frame is being destroyed. This is
+needed because frames are not reference counted. It's used by the event manager
+and other clients to ensure that any outstanding references to the frame are
+cleaned up.</Body>
+
+<SectionHeading><html:a name="Reflow">Reflow</html:a> Process</SectionHeading>
+<Note>The fact that are two reflow interfaces reflects an early
+goal of having core layout and HTML specific layout. The core reflow process would
+be the same for all frames, and each class of formatting objects (for
+example, CSS and DSSSL) would have their own reflow additions.</Note>
+
+<Body>The reflow process is a top-down protocol where a frame is given some
+available space and asked to reflow its child frames and return a desired
+size.</Body>
+
+<Body>The reflow process is not part of the nsIFrame interface. The generic reflow
+interface is defined in the nsIFrameReflow interface, and the HTML/CSS specific
+reflow interface is defined in the nsIHTMLReflow interface.</Body>
+
+<Body>An important part of the reflow process is the calculation of the computed
+values for the CSS properties. This includes things like 'width', 'height',
+and 'margin', and involves calculation of the containing block width and height
+and percentage based values and properties whose value is inherited.</Body>
+
+<Body>This process is encapsulated in the HTML specific reflow state struct
+(struct nsHTMLReflowState) that is passed in as part of reflow. The reflow
+states are linked together with the reflow state for a child frame pointing
+to its parent frame's reflow state. This allows us to walk up the reflow state
+structures and calculate containing block width and height and percentage
+based values.</Body>
+
+<Body>In addition to the computed values for the CSS box model properties, the
+following items are also included:
+<Items>
+<Item>reflow reason that indicates why the frame is being reflowed</Item>
+<Item>a rendering context that can be used to measure text</Item>
+<Item>reflow command (only used for incremental reflow)</Item>
+<Item>space manager</Item>
+</Items>
+</Body>
+
+<Body>The most common reflow reasons are 'eReflowReason_Resize' (the viewport
+has changed size) and 'eReflowReason_Incremental' (processing of an incremental
+reflow command).</Body>
+
+<Body>Reflow commands (see nsHTMLReflowCommand in mozilla/layout/html/base/src) are used
+to kick off an incremental reflow. They're generated either by the style system
+(in response to a style change) or by a frame itself (for example, if a frame has
+dirty child frames that need to be reflowed it will generate a reflow command).</Body>
+
+<Body>Reflow commands are queued by the presentation shell and then dispatched. Reflow
+commands have a target frame, which is the frame for which the reflow command
+is destined. In the example above the target frame is the frame with dirty child
+frames that need to be reflowed. Reflow command processing follows a path from
+the root frame down to the target frame.</Body>
+
+<Body>The space manager (see nsISpaceManager in mozilla/layout/base/public) is used
+when flowing text around floated elements. It has an API for managing bands of
+unavailable space (space that is reserved for a floated element). Internally it
+organizes the band data similar to how a region data structure works.</Body>
+
+<SectionHeading>Frame Classes</SectionHeading>
+<Body>There are four main categories of frame classes, all of which are located
+in mozilla/layout/html/src:
+
+<Categories>
+<Category>core frame classes</Category>
+<Category>table frame classes</Category>
+<Category>form frame classes</Category>
+<Category>frameset frame classes</Category>
+</Categories>
+</Body>
+
+<Body><RunIn>The core frame classes</RunIn> implement the CSS viewport abstraction, scrolling,
+block and inline display of flowed elements, floats, and absolute positioning.</Body>
+
+<Body>For more information on block layout, click
+<A xlink:type="simple" xlink:show="replace" xlink:href="block.html">here</A>. For more information about
+line layout, click <A xlink:type="simple" xlink:show="replace" xlink:href="line-layout.html">here</A>.</Body>
+
+<Body><RunIn>The table frame classes</RunIn> correspond to the HTML4 table spec, and in addition
+to the table frame there are row group frames, row frames, column group frames,
+column frames, and cell frames. There is an "outer" table frame as well that's
+really an anonymous frame that contains the caption frame and the table frame
+itself.</Body>
+
+<Body>Table layout is determined in a 3-step process. In the first step, the table
+is flowed into an infinitely wide and tall space. This gives us the minimum and
+desired sizes for every cell in the table. In the second step, the table constraints
+are factored in and widths are assigned to every cell. In the third step, heights are
+assigned to every cell based on the computed width constraint. The results of the first
+step are cached and only need to be recomputed when content or constraints are changed.</Body>
+
+<SectionHeading>Event Manager</SectionHeading>
+<Body>To be written</Body>
+
+</Documentation>
diff --git a/layout/doc/obsolete/line-layout.html b/layout/doc/obsolete/line-layout.html
new file mode 100644
index 000000000..3a1bd17fa
--- /dev/null
+++ b/layout/doc/obsolete/line-layout.html
@@ -0,0 +1,118 @@
+<!-- This Source Code Form is subject to the terms of the Mozilla Public
+ - License, v. 2.0. If a copy of the MPL was not distributed with this
+ - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
+
+<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.61 [en] (X11; I; Linux 2.2.5-22 i686) [Netscape]">
+</head>
+<body>
+
+<h1>
+<u>Line Layout</u></h1>
+Line layout is the process of placing inline frames horizontally (left
+to right or right to left depending on the CSS direction property value).
+An attempt is made to describe how it works.
+<p>nsLineLayout is the class that provides support for line layout. The
+container frames nsBlockFrame and nsInlineFrame use nsLineLayout to perform
+line layout and span layout. Span layout is a subset of line layout used
+for inline container classes - for example, the HTML "B" element). Because
+of spans, nsLineLayout handles the nested nature of line layout.
+<p>Line layout as a process contains the following steps:
+<ol>
+<li>
+Initialize the nsLineLayout object (done in nsBlockFrame). This prepares
+the line layout engine for reflow by initializing its internal data structures.</li>
+
+<br>&nbsp;
+<li>
+Reflowing of inline frames. The block code uses nsLineLayout's <b>ReflowFrame</b>
+method to reflow each inline frame in a line. This continues until the
+line runs out of room or the block runs out of frames. The block may be
+reflowing a span (an instance of nsInlineFrame) which will recursively
+use nsLineLayout for reflow and placement of the frames in the span.</li>
+
+<p><br>Note that the container frames (nsBlockFrame/nsInlineFrame) call
+nsLineLayout's ReflowFrame method instead of having the line layout code
+process a list of children. This is done so that the container frames can
+handle the issues of "pushing" and "pulling" of frames across continuations.
+Because block and inline maintain different data structures for their child
+lists, and because we don't want to mandate a common base class, the line
+layout code doesn't control the "outer loop" of frame reflow.
+<br>&nbsp;
+<li>
+Finish line layout by vertically aligning the frames, horizontally aligning
+the frames and relatively positioning the frames on the line.</li>
+</ol>
+nsLineLayout is also used by nsBlockFrame to construct text-run information;
+this process is independent of normal line layout is pretty much a hack.
+<p>When frames are reflowed they return a reflow status. During line layout,
+there are several additions to the basic reflow status used by most frames:
+<ul>
+<li>
+NS_FRAME_COMPLETE - this is a normal reflow status and indicates that the
+frame is complete and doesn't need to be continued.</li>
+
+<li>
+NS_FRAME_NOT_COMPLETE - this is another normal reflow status and indicates
+that the frame is not complete and will need a continuation frame created
+for it (if it doesn't already have one).</li>
+
+<li>
+NS_INLINE_BREAK - some kind of break has been requested. Breaks types include
+simple line breaks (like the BR tag in html sometime does) and more complex
+breaks like page breaks, float breaks, etc. Currently, we only support
+line breaks, and float clearing breaks. Breaks can occur before the frame
+(NS_INLINE_IS_BREAK_BEFORE) or after the frame (NS_INLINE_IS_BREAK_AFTER)</li>
+</ul>
+The handling of the reflow status is done by the container frame using
+nsLineLayout.
+<h3>
+<u>Line Breaking</u></h3>
+Another aspect of nsLineLayout is that it supports line breaking. At the
+highest level, line breaking consists of identifying where it is appropriate
+to break a line that doesn't fit in the available horizontal space. At
+a lower level, some frames are breakable (e.g. text) and some frames are
+not (e.g. images).
+<p>In order to break text properly, some out-of-band information is needed
+by the text frame code (nsTextFrame). In particular, because a "word" (a
+non-breakable unit of text) may span several frames (for example: <b>"&lt;B>H&lt;/B>ello
+there"</b> is breakable after the <b>"o"</b> in "<b>ello</b>" but not after
+the <b>"H"</b>), text-run information is used to allow the text frame to
+find adjacent text and look at them to determine where the next breakable
+point is. nsLineLayout supports this by keeping track of the text-runs
+as well as both storing and interrogating "word" state.
+<h3>
+<u>White-space</u></h3>
+To support the white-space property, the line layout logic keeps track
+of the presence of white-space in the line as it told to reflow each inline
+frame. This allows for the compression of leading whitespace and the compression
+of adjacent whitespace that is in separate inline elements.
+<p>As a post-processing step, the TrimTrailingWhiteSpace logic is used
+to remove those pesky pieces of white-space that end up being placed at
+the end of a line, that shouldn't really be seen.
+<p>To support pre-formatted text that contains tab characters, the line
+layout class keeps track of the current column on behalf of the text frame
+code.
+<h3>
+<u>Vertical Alignment</u></h3>
+Vertical alignment is peformed as a two and a half pass process. The first
+pass is done during nsInlineFrame reflow: the child frames of the nsInlineFrame
+are vertically aligned as best as can be done at the time. There are certain
+values for the vertical-align property that require the alignment be done
+after the lines entire height is known; those frames are placed during
+the last half pass.
+<p>The second pass is done by the block frame when all of the frames for
+a line are known. This is where the final height of the line
+<br>(not the line-height property) is known and where the final half pass
+can be done to place all of the top and bottom aligned elements.
+<br>&nbsp;
+<h3>
+<u>Horizontal Alignment</u></h3>
+After all frames on a line have been placed vertically, the block code
+will use nsLineLayout to perform horizontal alignment within the extra
+space.
+</body>
+</html>
diff --git a/layout/doc/obsolete/nav4-html.html b/layout/doc/obsolete/nav4-html.html
new file mode 100644
index 000000000..92aaebabd
--- /dev/null
+++ b/layout/doc/obsolete/nav4-html.html
@@ -0,0 +1,902 @@
+<!-- This Source Code Form is subject to the terms of the Mozilla Public
+ - License, v. 2.0. If a copy of the MPL was not distributed with this
+ - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
+
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="Author" CONTENT="Kipp E.B. HIckman">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (WinNT; I) [Netscape]">
+ <TITLE>HTML</TITLE>
+ <BASE HREF="file:///s|/ns/xena/htmlpars/testhtml/">
+</HEAD>
+<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#FF0000" VLINK="#800080" ALINK="#0000FF">
+
+<H2>
+HTML</H2>
+This documents describes the complete handling of HTML in magellan. The
+document covers the parsing process - how HTML is lexically analysized
+and then interprted. After the parsing process is discussed we give a detailed
+analysis of each HTML tag and the attributes that are supported, the values
+for the attributes and how the tag is treated by magellan.
+<H2>
+Parsing</H2>
+HTML is tokenized by an HTML scanner. The scanner is fed unicode data to
+parse. Stream converters are used to translate from various encodings to
+unicode. The scanner separates the input stream into tokens which consist
+of:
+<UL>
+<LI>
+text</LI>
+
+<LI>
+tags</LI>
+
+<LI>
+entities</LI>
+
+<LI>
+script-entities</LI>
+
+<LI>
+comments</LI>
+
+<LI>
+conditional comments</LI>
+</UL>
+The HTML parsing engine uses the HTML scanner for lexical anlaysis. The
+parsing engine operates by attacking the input stream in a set of well
+defined steps:
+<UL>
+<LI>
+The parser processes the head portion of the document first, without emitting
+any output. This is done to discover a few special features of html:</LI>
+
+<UL>
+<LI>
+The parser processes META tags looking for META TARGET</LI>
+
+<LI>
+The parser processes META tags looking for META tags which affect the character
+set. Nav4 handles the very first character set defining meta tag (all others
+are ignored) by reloading the document with the proper character conversion
+module inserted into the stream pipeline.</LI>
+</UL>
+
+<LI>
+After the head portion is processed the parser then proceeds to process
+the body of the document</LI>
+</UL>
+
+<H3>
+Tag Processing</H3>
+Tags are processed by the parser by locating a <B>"tag handler"</B> for
+the tag. The HTML parser serves as the tag handler for all of the builtin
+tags documented below. Tag attribute handling is done during translation
+of tags into content. This mapping translates the tag attributes into content
+data and into style data. The translation to style data is documented below
+by indicating the mapping from tag attributes to their CSS1 (plus extensions)
+equivalents.
+<H3>
+Special Hacks</H3>
+The following list describes hacks added to the magellan parsing engine
+to deal with navigator compatibility. These are just the parser hacks,
+not the layout or presentation hacks. Most hacks are intriduced for HTML
+syntax error recovering. HTML doesn't specify much how to handle those
+error conditions. Netscape has made big effort to render pages with non-prefect
+HTML. For many reasons, new browsers need to keep compatible in thsi area.
+<UL>
+<LI>
+Entities can be used as escape in quoted string. For value string in name-value
+pair,&nbsp; see <A HREF="../testhtml/quote001.html">compatibility test
+quote001.html</A>. Test line 70 shows that an entity quote at the begining
+means the value is NOT quoted. Test line 90 shows that if the value is
+started with a quote, then an entity quote does NOT terminate the value
+string.</LI>
+
+<LI>
+Wrapping tags are special tags such as title, textarea, server, script,
+style, and etc.. The comment in ns\lib\libparse\pa_parse.c says:</LI>
+
+<BR>&nbsp; /*
+<BR>&nbsp;&nbsp; * These tags are special in that, after opening one of
+them, all other tags are ignored until the matching
+<BR>&nbsp;&nbsp; * closing tag.
+<BR>&nbsp;&nbsp; */
+<BR>During the searching of an end tag, comments and quoted strings are
+observed. see <A HREF="../testhtml/title01.html">compatibility test title01.html</A>.
+6.0 handles comments now, need to add quoted string.
+<LI>
+If a &lt;tr> or &lt;td> tag is seen outside any &lt;table> scope, it is
+ignored. see <A HREF="../testhtml/table110.htm">compatibility test table110.htm</A>.</LI>
+
+<LI>
+<FONT COLOR="#000000">In case of table in table but not in cell, table
+tags before the last table tag are ignored. We found this problem in some
+Netscape public pages, see bug #85118. For example, &lt;table> &lt;table
+border> .....,or &lt;table> &lt;tr> &lt;table border>...,&nbsp; the table
+will be displayed with border.&nbsp;</FONT> <A HREF="../testhtml/table201.html">compatibility
+test table201.html</A>. There table and tr tags are buffered for this recovery.
+When a TD or CAPTION tag is open, the buffer is flushed out, because we
+cannot buffer contents of TD or CAPTION for performance and memory constrains.
+They are subdoc's and can be very big. If we see a &lt;table> outside cell
+after previous table is flushed out, the new &lt;table> tag is ignored.
+Nav4.0 can discard previous table in such case. <A HREF="../testhtml/tableall.html">tableall.html
+</A>is the index for table test cases.</LI>
+
+<LI>
+Caption is not a commonly used feature. In Nav4.0, captions can be anywhere.
+For Captions outside cells, the first one takes effect. For captions inside
+cells, the last one takes effect, and they also close TD and TR. In 6.0,
+caption is limited to the standard position: after &lt;table>. Captions
+in other places are ignored, their contents are treated as text. See test
+case table05a.html to table05o.html.</LI>
+
+<LI>
+<FONT COLOR="#000000">For &lt;table> &lt;tr> &lt;tr>, the first &lt;tr>
+takes effect.</FONT></LI>
+
+<LI>
+The nav4 parser notices when it hits EOF and it's in the middle of scanning
+in a comment. When this happens, the parser goes back and looks for an
+improperly closed comment (e.g. a simple > instead of a -->). If it finds
+one, it reparses the input after closing out the comment.</LI>
+
+<LI>
+<FONT COLOR="#FF0000">XXX Brendan also pointed out that there is something
+similar done for tags, but I don't recall what it is right now.</FONT></LI>
+
+<LI>
+<FONT COLOR="#000000">When Nav4.0 sees the '&lt;' sign, it searchs for
+'>', observing quoted values. If it cannot find one till EOF, the '&lt;'
+sign is treated as text. In Xena 6.0, a limit is set for how far the '>'
+is searched. the default limit is 4096 char, and there is a API HTMLScanner.setMaxTagLength()
+to changed it. setting -1 means no limit, which is same as Nav4.0.</FONT></LI>
+</UL>
+<FONT COLOR="#FF0000">TODO:</FONT>
+<UL><FONT COLOR="#FF0000">Document the mapping of tag attributes into CSS1
+style, including any new "css1" attributes</FONT>
+<BR>&nbsp;</UL>
+<B>List of 6.0 features incompatible with 4.0</B>
+<UL>
+<LI>
+Navigator 4.0 value string is truncated at 82 characters. XENA60 limit
+is MAX_STRING_LENGTH = 2000.</LI>
+
+<BR>&nbsp;</UL>
+
+<HR WIDTH="100%">
+<H2>
+Tags (Categorically sorted)</H2>
+All line breaks are conditional. If the x coordinate is at the current
+left margin then a soft line break does nothing. Hard line breaks are ignored
+if the last tag did a hard line break.
+
+<P><B>divalign</B> = left | right | center | justify
+<BR><B>alignparam</B> = abscenter | left | right | texttop | absbottom
+| baseline | center | bottom | top | middle | absmiddle
+<BR><B>colorspec</B> = named-color | #xyz | #xxyyzz | #xxxyyyzzz | #xxxxyyyyzzzz
+<BR><B>clip</B> = [auto | value-or-pct-xy](1..4) (pct of width for even
+coordinates; pct of height for odd coordinates)
+<BR><B>value-or-pct = </B>an integer with an optional %; ifthe percent
+is present any following characters are ignored!
+<BR><B>coord-list</B> = <FONT COLOR="#DD0000">XXX</FONT>
+<BR><FONT COLOR="#000000"><B>whitespace-strip</B> = remove leading and
+trailing and any embedded whitespace that is not an actual space (e.g.
+newlines)</FONT>
+<H1>
+Head objects:</H1>
+<B>TITLE</B>
+<UL>The TITLE tag is a container tag whose contents are not HTML. The contents
+are pure text and are processed by the parser until the closing tag is
+found. There are no attributes on the tag and any whitespace present in
+the tag is compressed down with leading and trailing whitespace eliminated.
+The first TITLE tag found by the parser is used as the document's title
+(subsequent tags are ignored).</UL>
+<B>BASE</B>
+<UL>Sets the base element in the head portion of the document. Defines
+the base URL for <FONT COLOR="#DD0000">all</FONT>? links in the document.
+<BR>Attributes:
+<UL><B>HREF</B>=url [This is an absolute URL]
+<BR><B>TARGET</B>=string [must start with XP_ALPHA|XP_DIGIT|underscore
+otherwise nav4 ignores it]</UL>
+</UL>
+<B>META</B>
+<UL>Can define several header fields (content-encoding, author, etc.)
+<BR>Attributes:
+<UL><B>REL</B>=SMALL_BOOKMARK_ICON|LARGE_BOOKMARK_ICON
+<UL><B>SRC</B>=string</UL>
+<B>HTTP-EQUIV</B>="header: value"
+<UL><B>CONTENT</B>=string</UL>
+</UL>
+HTTP-EQUIV values (from libnet/mkutils.c NET_ParseMimeHeader):
+<UL>ACCEPT-RANGES
+<BR>CONTENT-DISPOSITION
+<BR>CONTENT-ENCODING
+<BR>CONTENT-RANGE
+<BR>CONTENT-TYPE [ defines character set only ]
+<BR>CONNECTION
+<BR>DATE
+<BR>EXPIRES
+<BR>EXT-CACHE
+<BR>LOCATION
+<BR>LAST-MODIFIED
+<BR>LINK
+<BR>PROXY-AUTHENTICATE
+<BR>PROXY-CONNECTION
+<BR>PRAGMA
+<BR>RANGE
+<BR>REFRESH
+<BR>SET-COOKIE
+<BR>SERVER
+<BR>WWW-AUTHENTICATE
+<BR>WWW-PROTECTION-TEMPLATE
+<BR>WINDOW-TARGET</UL>
+Style sheets and HTML w3c spec adds this:
+<UL>CONTENT-STYLE-TYPE [ last one wins; overrides header from server if
+any ]</UL>
+</UL>
+<B>LINK</B>
+<UL>List related resources. Used by extensions mechanism to find tag handlers.
+<FONT COLOR="#0000FF">/LINK == LINK!</FONT>
+<BR>Attributes:
+<UL><B>REL</B>=FONTDEF
+<UL><B>SRC</B>=url</UL>
+<B>REL</B>=STYLESHEET [ If MEDIA param is defined it must ==nc screen ]
+<UL><B>LANGUAGE</B>=LiveScript|Mocha|JavaScript1.1|JavaScript1.2
+<BR><B>TYPE</B>="text/javascript" | "text/css"
+<BR><B>HREF</B>=url
+<BR><B>ARCHIVE</B>=url
+<BR><B>CODEBASE</B>=url
+<BR><B>ID</B>=string
+<BR><B>SRC</B>=url</UL>
+</UL>
+Note: HREF takes precedence over SRC in nav4.</UL>
+<B>HEAD</B>
+<UL>/HEAD clears the "in_head" flag (but leaves the "in_body" flag alone.
+<BR>Text in head clears in_head, and set in_body true, just as if the author
+forgot the /HEAD tag.
+<BR>Attributes: none</UL>
+<B>HTML</B>
+<UL>Ignored.
+<BR>Attributes: none</UL>
+<B>STYLE</B>
+<UL>Allowed anywhere in the document. Note that entities are not parsed
+in the style tag's content.
+<BR>Attributes:
+<UL><B>LANGUAGE</B>=LiveScript|Mocha|JavaScript1.1|JavaScript1.2
+<BR><B>TYPE</B>="text/javascript" | "text/css"
+<BR><B>HREF</B>=url
+<BR><B>ARCHIVE</B>=url
+<BR><B>CODEBASE</B>=url
+<BR><B>ID</B>=string
+<BR><B>SRC</B>=url</UL>
+</UL>
+<B>FRAMESET</B>
+<UL>Frameset with rows=1 and cols=1 is ignored.
+<BR>Attributes:
+<UL><B>FRAMEBORDER</B>= no | 0 (zero) [default is no_edges=false]
+<BR><B>BORDER</B>= int [clamped: >= 0 &amp;&amp; &lt;= 100]
+<BR><B>BORDERCOLOR</B>= color
+<BR><B>ROWS</B>= pct-list
+<BR><B>COLS</B>= pct-list</UL>
+</UL>
+<B>FRAME</B>
+<UL>Border width of zero disables edges.
+<BR>Attributes:
+<UL><B>FRAMEBORDER</B>= no | 0 (zero) [default is framesets value]
+<BR><B>BORDER</B>= int [clamped; >= 0 &amp;&amp; &lt;= 100]
+<BR><B>BORDERCOLOR</B>= color
+<BR><B>NORESIZE</B>= true [default is false]
+<BR><B>SCROLLING</B>= yes | scroll | on | no | noscroll | off
+<BR><B>SRC</B>= url [clamped: prevent recursion by eliminating any anscestor
+references]
+<BR><B>NAME</B>= string
+<BR><B>MARGINWIDTH</B>= int (clamped: >= 1)
+<BR><B>MARGINHEIGHT</B>= int (clamped: >= 1)</UL>
+</UL>
+<B>NOFRAMES</B>
+<UL>Used when frames are disabled or for backrev browsers. Has no stylistic
+consequences.</UL>
+
+<H1>
+
+<HR WIDTH="100%">Body objects:</H1>
+&nbsp;<B>BODY</B>
+<UL>The tag is only processed on open tags and it is always processed.
+See ns\lib\layout\laytags.c, searching for "case P_BODY". During tag processing
+the in_head flag is set to false and the in_body flag is set to true. An
+attribute is ignored if the document already has that attribute set. Attributes
+can be set by style sheets, or by previous BODY tags. see <A HREF="../testhtml/head02.html">test
+head02.html</A>.
+<BR>Attributes:
+<UL><B>MARGINWIDTH</B>=int [clamped: >= 0 &amp;&amp; &lt; (windowWidth/2
+- 1)]
+<BR><B>MARGINHEIGHT</B>=int [clamped: >= 0 &amp;&amp; &lt; (windowHeight/2
+- 1)]
+<BR><B>BACKGROUND</B>=url
+<BR><B>BGCOLOR</B>=colorspec
+<BR><B>TEXT</B>=colorspec
+<BR><B>LINK</B>=colorspec
+<BR><B>VLINK</B>=colorspec
+<BR><B>ALINK</B>=colorspec
+<BR><B>ONLOAD, ONUNLOAD, UNFOCUS, ONBLUR, ONHELP</B>=script
+<BR><B>ID</B>=string</UL>
+</UL>
+<B>LAYER, ILAYER</B>
+<UL>Open layer/ilayer tag automaticly close out an open form if one is
+open. It does something to the soft linebreak state too.
+<BR>Attributes:
+<UL><B>LEFT</B>=value-or-pct (pct of <TT>right-left</TT> margin)
+<BR><B>PAGEX</B>=x (if no LEFT)
+<BR><B>TOP</B>=value-or-pct
+<BR><B>PAGEY</B>=y (if no TOP)
+<BR><B>CLIP</B>=clip
+<BR><B>WIDTH</B>=value-or-pct (pct of <TT>right-left</TT> margin)
+<BR><B>HEIGHT</B>=value-or-pct
+<BR><B>OVERFLOW</B>=string
+<BR><B>NAME</B>=string
+<BR><B>ID</B>=string
+<BR><B>ABOVE</B>=string
+<BR><B>BELOW</B>=string
+<BR><B>ZINDEX</B>=int [any value]
+<BR><B>VISIBILITY</B>=string
+<BR><B>BGCOLOR</B>=colorspec
+<BR><B>BACKGROUND</B>=url</UL>
+</UL>
+<B>NOLAYER</B>
+<UL>Container for content which is used when layers are disabled or unsupported.
+The content has no style consequences (though it could if somebody stuck
+in some CSS1 style rules for it).</UL>
+<B>P</B>
+<UL>Closes the paragraph. If the attribute is present then an alignment
+gets pushed on the alignment stack. All values are supported by nav4.
+<BR>Attributes:
+<UL><B>ALIGN</B>=divalign</UL>
+</UL>
+<B>ADDRESS</B>
+<UL>There are no attributes. ADDRESS closes out the open paragraph. The
+open tag does a conditional soft line break and then pushes a merge of
+the current style with italics enabled onto the style stack. The close
+always pop the style stack and also does a conditional soft line break.</UL>
+<B>PLAINTEXT, XMP</B>
+<UL>PLAINTEXT causes the remaining content to no longer be parsed. XMP
+causes the content to not parse entities or other tags. The XMP can be
+closed by it's own tag (on any boundary); PLAINTEXT is not closed (html3.2
+allows it to be closed). Both tags change the style to a fixed font of
+a</UL>
+<B>LISTING</B>
+<UL>Closes the paragraph. Does a hard line break on open and close. Open
+pushes a fixed width font style of a particular font size on the style
+stack. The close tag pops the top of the style stack.
+<BR>Attributes: none</UL>
+<B>PRE</B>
+<UL>Closes the paragraph. The open tag does a hard line break. A fixed
+font style (unless VARIABLE is present) is pushed on the style stack. The
+close tag pops the top of the style stack. It also does a hard line break.
+<BR>Attributes:
+<UL><B>WRAP</B>
+<BR><B>COLS</B>=int [clamped: >= 0]
+<BR><B>TABSTOP</B>=int [clamped: >= 0; clamped value is replaced with default
+value]
+<BR><B>VARIABLE</B></UL>
+</UL>
+<B>NOBR</B>
+<UL>This tag doesn't nest. Instead it just sets or clears a flag in the
+state machine. It has no effect on any other state.</UL>
+<B>CENTER</B>
+<UL>Closes the paragraph. Always does a conditional soft line break. The
+open tag pushes an alignment on the aligment stack. The close tag pops
+the top alignment off.
+<BR>Attributes: none</UL>
+<B>DIV</B>
+<UL>Closes the paragraph. Always does a conditional soft line break. COLS
+defines the number of columns to layout in (like MULTICOL). The open tag
+pushes an alignment on the alignment stack (if COLS > 1 then it pretends
+to be a MULTICOL tag). The close tag pops an aligment from the alignment
+stack.
+<BR>Attributes:
+<UL><B>ALIGN</B>=divalign
+<BR><B>COLS</B>=int [if cols > 1 then DIV acts like a MULTICOL tag else
+DIV is just a container]
+<UL><B>GUTTER</B>= int (clamped: >= 1)
+<BR><B>WIDTH</B>= value-or-pct [pct of right-left margin; clamped >= 1/0
+(strange code)]</UL>
+</UL>
+</UL>
+<B>H1-H6</B>
+<UL>Closes the paragraph. The open tag does a hard line break and pushes
+a style item which enables bold and disables fixed and italic. The close
+tag always pops the top item from the style stack. It also does a hard
+line break. If the <B>ALIGN</B> attribute is present then the open tag
+pushes an alignment on the alignment stack. The close tag will look at
+the top of the alignment stack and if its a header of any kind (H1 through
+H6) then the alignment is popped. In either case the close tag also does
+a conditional soft line break (this happens before the hard line break).
+<BR>Attributes:
+<UL><B>ALIGN</B>=divalign</UL>
+</UL>
+A note regarding closing paragraphs: Any time a close paragraph is done
+(for any tag) if the top of the alignment stack has a tag named "P" then
+a conditional soft line break is done and the alignment is popped.
+<H3>
+
+<HR ALIGN=LEFT WIDTH="50%"></H3>
+<B>TABLE</B>
+<UL>Close the paragraph.
+<BR>Attributes:
+<UL><B>ALIGN=</B>left|right|center|abscenter
+<BR><B>BORDER</B>=int [clamped: if null then -1, if &lt; 1 then 1 ]
+<BR><B>BORDERCOLOR</B>=string [if not supplied then set to the text color
+]
+<BR><B>VSPACE</B>=int [ clamped: >= 0 ]
+<BR><B>HSPACE</B>=int [ clamped: >= 0 ]
+<BR><B>BGCOLOR</B>=color
+<BR><B>BACKGROUND</B>=url
+<BR><B>WIDTH</B>=value-or-pct [ % of win.width minus margins; clamped:
+>= 0 ]
+<BR><B>HEIGHT</B>=value-or-pct [ % of win.height minus margins; clamped:
+>= 0 ]
+<BR><B>CELLPADDING</B>=int [clamped: >= 0; separate pads take precedence
+]
+<BR><B>TOPPADDING</B>= int [clamped: >= 0 ]
+<BR><B>BOTTOMPADDING</B>= int [clamped: >= 0 ]
+<BR><B>LEFTPADDING</B>= int [clamped: >= 0 ]
+<BR><B>RIGHTPADDING</B>= int [clamped: >= 0 ]
+<BR><B>CELLSPACING</B>= int [clamped: >= 0 ]
+<BR><B>COLS</B>=int [clamped: >= 0]</UL>
+The code supports more attributes in the Table attribute handler than it
+does in the code that gets the attributes from the tag! They are border_top,
+border_left, border_right, border_bottom, border_style (defaults to outset;
+allows for outset/dotted/none/dashed/solid/double/groove/ridge/inset).</UL>
+<B>TR</B>
+<UL>Open TR automatically closes an open table row (and an open table cell
+if one is open). It also automatically closes a CAPTION tag.
+<BR>Attributes:
+<UL><B>BGCOLOR</B>=color
+<BR><B>BACKGROUND</B>=url
+<BR><B>VALIGN</B>=top|bottom|middle|center(==middle)|baseline; default
+is top
+<BR><B>ALIGN</B>=left|right|middle|center(==middle); default is left</UL>
+</UL>
+<B>TH, TD</B>
+<UL>If no table then the tag is ignored (open or close). If no row is currently
+opened or the current row is current done (because of a &lt;/TR> tag) then
+a new row is begun. Oddly enough the tag parameters for the row come from
+the TH/TD tag in this case. An open of either of these tags will automatically
+close the previous cell.
+<BR>Attributes:
+<UL><B>COLSPAN</B>=int [clamped: >= 1 &amp;&amp; &lt;= 1000 ]
+<BR><B>ROWSPAN</B>=int [clamped: >= 1 &amp;&amp; &lt;= 10000 ]
+<BR><B>NOWRAP</B> [boolean: disables wrapping ]
+<BR><B>BGCOLOR</B>=color [default: inherit from the row; if not row then
+table; if not table then inherit from an outer table cell; this works because
+the style is flattened so the outer table cell will have a color]
+<BR><B>BACKGROUND</B>=url [same rules as bgcolor for inheritance; tile
+mode is inherited too and not settable by TH/TD attributes (have to use
+style sheets for that)]
+<BR><B>VALIGN</B>=top|bottom|middle|center(==middle)|baseline; default
+is top
+<BR><B>ALIGN</B>=left|right|middle|center(==middle); default is left
+<BR><B>WIDTH</B>=value-or-pct [ clamped: >= 0 ]
+<BR><B>HEIGHT</B>=value-or-pct [ clamped: >= 0 ]</UL>
+</UL>
+<B>CAPTION</B>
+<UL>An open caption tag will automatically close an open table row (and
+an open cell).
+<BR>Attributes:
+<UL><B>ALIGN</B>=bottom</UL>
+The code sets the vertical alignment to top w/o providing a mechanism for
+the user to set it (there is no VALIGN attribute).</UL>
+<B>MULTICOL</B>
+<UL>The open tag does a hard line break. The close tag checks to see if
+the state machine has an open multicol and if it does then it does a conditional
+soft line break and then continues to break until both margins are cleared
+of floating elements. It recomputes the margins based on the list indenting
+level (?). After the synthetic table is output the close tag does a hard
+line break.
+
+<P>This tag will treat the input as source for a table with one row and
+COLS columns. The data is laid out using the width divided by the number
+of columns. After the total height is known, the content is partitioned
+as evenly as possible between the columns in the table.
+<BR>Attributes:
+<UL><B>COLS</B>=int [clamped: values less than 2 cause the tag to be ignored]
+<BR><B>GUTTER</B>=int [clamped: >= 1]
+<BR><B>WIDTH</B>=value-or-pct [pct of right-left margin; clamped: >= 1/0
+(strange code)]</UL>
+</UL>
+
+<H3>
+
+<HR ALIGN=LEFT WIDTH="50%"></H3>
+<B>BLOCKQUOTE</B>
+<UL>Closes the paragraph. The open tag does a hard line break. A list with
+the empty-bullet style is pushed on the list stack (unless TYPE=cite/jwz
+then a styled list is pushed). The close tag pops any list and does a hard
+line break.
+<BR>Attributes:
+<UL><B>TYPE</B>=cite | jwz</UL>
+</UL>
+<B>UL, OL, MENU, DIR</B>
+<UL>For top-level lists (lists not in lists) a hard break is done on the
+open tag, otherwise a conditional-soft-break is done. Tag always does a
+close paragrah. The close tag does a conditional soft line break when nested;
+when not nested the close tag does a hard line break (even if no list is
+open). The open tag pushes the list on the list stack. The close tag pops
+any list off the list stack.
+<BR>Attributes:
+<UL><B>TYPE</B>= none | disc | circle | round | square | decimal | lower-roman
+| upper-roman | lower-alpha | upper-alpha | A | a | I | i [clamped: if
+none of the above is picked and OL then the bullet type is "number" otherwise
+the bullet type is "basic"]
+<BR><B>START</B>=int [clamped: >= 1]
+<BR><B>COMPACT</B></UL>
+</UL>
+<B>DL</B>
+<UL>Closes the paragraph. For the open tag, if the list is nested then
+a conditional soft line break is done otherwise a hard line break is done.
+The open tag pushes a list on the list stack. The close tag pops any list
+from the list stack. Closing the list acts like other lists closes.
+<BR>Attributes:
+<UL><B>COMPACT</B></UL>
+</UL>
+<B>LI</B>
+<UL>Closes the paragraph. The open tag does a conditional soft line break.
+Close tags are ignored (except for closing the paragraph).
+<BR>Attributes:
+<UL><B>TYPE</B>= A | a | I | i (if the containing list is an <B>OL</B>)
+<BR><B>TYPE</B>= round | circle | square (if the containing list is not
+<B>OL</B> and not <B>DL</B>)
+<BR><B>VALUE</B>=int [clamped: >= 1]</UL>
+The magellan html parser allows the full set of list item styles from the
+OL/DL tag instead of just the limited set that nav4 allows.</UL>
+<B>DD</B>
+<UL>Closes the paragraph. Close tags are ignored (except for closing the
+paragraph). DD outside a DL just advances the X coordinate of layout by
+a small constant. DD inside a DL does a conditional soft line break and
+other margin crud.
+<BR>Attributes: none.</UL>
+<B>DT</B>
+<UL>Closes the paragraph (open or close). Close tags are otherwise ignored.
+Does a conditional soft line break. Moves the X layout coordinate to the
+left margin.
+<BR>Attributes: none</UL>
+
+<H3>
+
+<HR ALIGN=LEFT WIDTH="50%"></H3>
+<B>A</B>
+<UL>Open anchors push a style on the style stack if the anchor has an <B>HREF</B>.
+Close anchors pop as many styles off the top of the style stack that are
+anchor tags (anchor tags don't nest in other words). In addition, any styles
+on the stack that have the ANCHOR bit set have it cleared and fiddle with
+the foreground and background colors.
+<BR>Attributes:
+<UL><B>NAME</B>=string
+<BR><B>HREF</B>=url
+<UL><B>TARGET</B>=target
+<BR><B>SUPPRESS</B>=true</UL>
+</UL>
+</UL>
+<B>STRIKE, S, TT, CODE, SAMPLE, KBD, B, STRONG, I, EM, VAR, CITE, BLINK,
+BIG, SMALL, U, INLINEINPUT, SPELL</B>
+<UL>The open tag pushes onto the style stack. The close tag always pops
+the top item from the style stack.
+<BR>Attributes: none</UL>
+<B>SUP, SUB</B>
+<UL>The open tag pushes a font size descrease on the style stack. The close
+tag always pops the top of the style stack. The open and close tag impacts
+the baselineThe only difference between SUP and SUB is how they impact
+the baseline. Note that the baseline information is forgotten after a line
+break; therefore a close SUP/SUB on the next line will do strange things.
+<BR>Attributes: none</UL>
+<B>SPAN</B>
+<UL>Ignored by the navigator.
+<BR>Attributes: none</UL>
+<B>FONT</B>
+<UL>The open font tag with no attributes resets the font size to the base
+font size. The open tag always pushes a style stack entry. The close tag
+always pops the top item off the style stack.
+<BR>Attributes:
+<UL><B>SIZE</B>=[+ int | - int | int ]&nbsp; [clamped: >=1 &amp;&amp; &lt;=
+7]
+<BR><B>POINT-SIZE=</B>[+ int | - int | int ] [clamped: >= 1 &amp;&amp;
+&lt;= 1600]
+<BR><B>FONT-WEIGHT</B>=[+ int | - int | int ] [clamped: >= 100 &amp;&amp;
+&lt;= 900]
+<BR><B>COLOR</B>=colorspec
+<BR><B>FACE</B>=string</UL>
+</UL>
+A note regarding the style stack: The pop of the stack checks to see if
+the top of the stack is an ANCHOR tag. If it is not an anchor then the
+top item is unconditionally popped. If the top of the style stack is an
+anchor tag then the code searches for either the bottom of the stack or
+the first style stack entry not created by an anchor tag. If the entry
+is followed by another entry then the entry is removed from the stack (an
+out-of-order pop in other words). In this case the anchor style stack entry
+is left untouched.
+<H3>
+
+<HR ALIGN=LEFT WIDTH="50%"></H3>
+<B>text, entities</B>
+<UL>These are basic content objects that get fed directly to the output.
+In navigator the text is processed by doing line-breaking (entities have
+been converted to text already by the parser). The line-breaking is controlled
+by the margin settings and the list depth, the floating elements, the style
+attributes (font size, etc.), the preformatted flag, the no-break flag
+and so on.</UL>
+<B>IMG, IMAGE</B>
+<UL>Close tag is ignored.
+<BR>Attributes:
+<UL><B>ISMAP</B>
+<BR><B>USEMAP</B>=url
+<BR><B>ALIGN</B>=alignparam
+<BR><B>SRC</B>=url [ whitespace is stripped ]
+<BR><B>LOWSRC</B>=url
+<BR><B>ALT</B>=string
+<BR><B>WIDTH</B>=value-or-pct (pct of <TT>right-left</TT> width)
+<BR><B>HEIGHT</B>=value-or-pct (pct of window height)
+<BR><B>BORDER</B>=int [clamped: >= 0]
+<BR><B>VSPACE</B>=int [clamped: >= 0]
+<BR><B>HSPACE</B>=int [clamped: >= 0]
+<BR><B>SUPPRESS</B>=true | false (only in blocked image layout???)</UL>
+</UL>
+<B>HR</B>
+<UL>Closes the paragraph. If an open tag then does a conditional soft line
+break. The rule inherits alignment from the parent container unless there
+is no container (then it's centered) or if the tag defines it's own alignment.
+After the object is inserted into the layout stream a soft line break is
+inserted as well.
+<BR>Attributes:
+<UL><B>ALIGN</B>=divalign (sort of; in laytags.c it's divalign; in layhrule.c
+it's left or right only)
+<BR><B>SIZE</B>=int (1 to 100 inclusive)
+<BR><B>WIDTH</B>=val-or-pct (pct of <TT>right-left</TT> width)
+<BR><B>NOSHADE</B></UL>
+</UL>
+<B>BR</B>
+<UL>Does an unconditional soft break. If clear is set then it will also
+soft break until either the left or right or both margins are clear of
+floating elements. Note that<FONT COLOR="#0000FF"> /BR == BR!</FONT>
+<BR>Attributes:
+<UL><B>CLEAR</B>=left | right | all | both</UL>
+</UL>
+<B>WBR</B>
+<UL>Soft word break.
+<BR>Attributes: none</UL>
+<B>EMBED</B>
+<UL>Close tag does nothing. Embed's operate inline just like images (they
+don't close the paragraph).
+<BR>Attributes:
+<UL><B>HIDDEN</B>=no | false | off
+<BR><B>ALIGN</B>=alignparam
+<BR><B>SRC</B>=url
+<BR><B>WIDTH</B>=val-or-pct (pct of <TT>right-left</TT> width)
+<BR><B>HEIGHT</B>=val-of-pct; if val is &lt; 1 (sometimes) the element
+gets HIDDEN automatically
+<BR><B>BORDER</B>=int (unsupported by navigator)
+<BR><B>VSPACE</B>=int [clamped: >= 0]
+<BR><B>HSPACE</B>=int [clamped: >= 0]</UL>
+</UL>
+<B>NOEBMED</B>
+<UL>Used when EMBED's are disabled. It is a container for regular content
+that has no stylistic consequences (no line breaking, no style stack effect,
+etc.).</UL>
+<B>APPLET</B>
+<UL>Applet tags don't nest (there is a notion of current_applet). The open
+tag automatically closes an open applet tag.
+<BR>Attributes:
+<UL><B>ALIGN</B>=alignparam
+<BR><B>CODE</B>=string
+<BR><B>CODEBASE</B>=string
+<BR><B>ARCHIVE</B>=string
+<BR><B>MAYSCRIPT</B>
+<BR><B>NAME</B>=string [clamped: white space is stripped out]
+<BR><B>WIDTH</B>=value-or-pct [pct of right-left width; clamped: >= 1]
+<BR><B>HEIGHT</B>=value-or-pct [pct of window height; clamped >= 1]
+<BR><B>BORDER</B>=int [clamped: >= 0]
+<BR><B>HSPACE</B>=int [clamped: >= 0]
+<BR><B>VSPACE</B>=int [clamped: >= 0]</UL>
+If no width is provided:
+<UL>if a height was provided, use the height. Otherwise, use 90% of the
+window width if percentage widths are allowed, otherwise use a value of
+600.
+<BR>&nbsp;</UL>
+If no height is provided:
+<UL>if a width was provided, use the width. Otherwise, use 50% of the window
+height if percentage widths are allowed, otherwise use a value of 400.</UL>
+If the applet is hidden, then the widht/height get forced to zero.</UL>
+<B>PARAM</B>
+<UL>The param tag is supported when contained by the APPLET tag or the
+OBJECT tag. It has no stylistic consequences. The attribute values from
+the tag are passed to the containing APPLET or OBJECT. Note that <FONT COLOR="#0000FF">/PARAM
+== PARAM</FONT>.
+<BR>Attributes:
+<UL><B>NAME</B>=string [clamped: white space is stripped out]
+<BR><B>VALUE</B>=string [clamped: white space is stripped out]</UL>
+White space being stripped is done as follows: leading and trailing whitespace
+is removed. Any embedded whitespace is left alone except if it's a non-space
+whitespace in which case it is removed.</UL>
+<B>OBJECT</B>
+<UL>The open tag pushes an object onto the object stack. The close tag
+pops from the object stack. I don't understand how the data stuff works.
+<BR>Attributes:
+<UL><B>CLASSID</B>=string (clsid:, java:, javaprogram:, javabean: are the
+supported prefixes; maybe it's a url if no prefix shown?)
+<BR><B>TYPE</B>=string (a mime type)
+<BR><B>DATA</B>=string (data: prefix mentions a url)</UL>
+There are more attributes that depend on the type of object being embedded
+in the page. If the object is a java bean (?) then the applet parameters
+are supported:
+<UL>CLASSID
+<BR>HIDDEN
+<BR>ALIGN
+<BR>CLASSID (instead of CODE)
+<BR>CODEBASE
+<BR>ARCHIVE
+<BR>MAYSCRIPT
+<BR>ID (applets use NAME)
+<BR>WIDTH
+<BR>HEIGHT
+<BR>BORDER
+<BR>HSPACE
+<BR>VSPACE</UL>
+</UL>
+<B>MAP</B>
+<UL>The open tag automatically closes an open map (maps don't nest). There
+is no stylistic consequence of the map nor does it provide any visible
+presentation in the normal layout case (an editor would do something different).
+The map can be declared anywhere in the document.
+<BR>Attributes:
+<UL><B>NAME</B>=string [clamped: white space is stripped out]</UL>
+</UL>
+<B>AREA</B>
+<UL>Does nothing if there is no current map or the tag is a close tag.
+<BR>Attributes:
+<UL><B>SHAPE</B>=default | rect | circle | poly | polygon
+<BR><B>ALT</B>=string [clamped: newlines are stripped]
+<BR><B>COORDS</B>=coord-list
+<BR><B>HREF=</B>url
+<UL><B>TARGET</B>=target (only if HREF is specified)</UL>
+<B>SUPPRESS</B></UL>
+</UL>
+<B>SERVER</B>
+<UL>A container for server-side javascript. Not evaluated by the client
+(parsed and ignored). Note: The navigator parser doesn't expand entities
+in a <B>SERVER </B>tag.</UL>
+<B>SPACER</B>
+<UL>Close tag is ignored. Open tag provides whitespace during layout: <B>TYPE</B>=line/vert/vertical
+causes a conditional soft line break and then adds <B>SIZE </B>to the Y
+layout coordinate. <B>TYPE</B>=word causes a conditional soft word break
+and then adds <B>SIZE </B>to the X layout coordinate. <B>TYPE</B>=block
+causes <FONT COLOR="#DD0000">blockish </FONT>layout stuff to happen.
+<BR>Attributes:
+<UL><B>TYPE</B>=line | vert | vertical | block (default: word)
+<UL><B>ALIGN</B>=alignparam (these 3 params are only for <B>TYPE</B>=block)
+<BR><B>WIDTH</B>=value-or-pct
+<BR><B>HEIGHT</B>=value-or-pct</UL>
+<B>SIZE</B>=int [clampled: >= 0]</UL>
+</UL>
+
+<H3>
+
+<HR ALIGN=LEFT WIDTH="50%"></H3>
+<B>SCRIPT</B>
+<UL>Note: The navigator parser doesn't expand entities in a SCRIPT tag.
+<BR>Attributes:
+<UL><B>LANGUAGE</B>=LiveScript | Mocha | JavaScript1.1 | JavaScript1.2
+<BR><B>TYPE</B>="text/javascript" | "text/css"
+<BR><B>HREF</B>=url
+<BR><B>ARCHIVE</B>=url
+<BR><B>CODEBASE</B>=url
+<BR><B>ID</B>=string
+<BR><B>SRC</B>=url</UL>
+</UL>
+<B>NOSCRIPT</B>
+<UL>Used when scripting is off or by backrev browsers. It is a container
+that has no stylistic consequences.</UL>
+
+<H3>
+
+<HR ALIGN=LEFT WIDTH="50%"></H3>
+<B>FORM&nbsp;</B>
+<UL>Attributes:
+<UL><B>ACTION</B>=href
+<BR><B>ENCODING</B>=string
+<BR><B>TARGET</B>=string
+<BR><B>METHOD</B>=get | post</UL>
+</UL>
+<B>ISINDEX&nbsp;</B>
+<UL>This tag is a shortcut for creating a form element with a submit button
+and a single text field. If the PROMPT attribute is not present in the
+tag then the value used is <B>"This is a searchable index. Enter search
+keywords:"</B>.
+
+<P>Attributes:
+<UL><B>PROMPT</B>=string
+<BR><B>ACTION</B>=href
+<BR><B>ENCODING</B>=string
+<BR><B>TARGET</B>=string
+<BR><B>METHOD</B>=get | post</UL>
+</UL>
+<B>INPUT&nbsp;</B>
+<UL>Attributes vary according to type:
+<UL><B>TYPE</B>= text | radio | checkbox | hidden | submit | reset | password
+| button | image | file | jot | readonly | object
+<BR><B>NAME</B>= string
+<BR>&nbsp;</UL>
+<B>TYPE</B>=image
+<UL>attributes are from the IMG tag (!)</UL>
+<B>TYPE</B>= text | password | file
+<UL>font style is forced to fixed
+<BR><B>VALUE</B>= string
+<BR><B>SIZE</B>= int (clamped; >= 1)
+<BR><B>MAXLENGTH</B>= int (not clamped!)</UL>
+<B>TYPE</B>= submit | reset | button | hidden | readonly
+<UL><B>VALUE</B>=string; default if no value to the attribute varies according
+to the type:
+<UL><B>submit</B> -> "Submit Query"
+<BR><B>reset</B> -> "Reset"
+<BR>others -> "&nbsp; " (2 spaces)
+<BR>Note also that the value has newlines stripped from it</UL>
+<B>WIDTH</B>=int (clamped >=0 &amp;&amp; &lt;= 1000) (only for submit,
+reset or button)
+<BR><B>HEIGHT</B>=int (clamped >=0 &amp;&amp; &lt;= 1000) (only for submit,
+reset or button)</UL>
+<B>TYPE</B>=radio | checkbox
+<UL><B>CHECKED</B> (flag - if present then set to true)
+<BR><B>VALUE</B>= string (the default value is "on")</UL>
+</UL>
+<B>SELECT&nbsp;</B>
+<UL>Attributes:
+<UL><B>MULTIPLE</B> (boolean)
+<BR><B>SIZE</B>= int (clamped >= 1)
+<BR><B>NAME=</B> string
+<BR><B>WIDTH</B>= int (clampled >= 0 &amp;&amp; &lt;= 1000)
+<BR><B>HEIGHT</B>= int (clamped >= 0 &amp;&amp; &lt;= 1000; only examined
+for single entry lists (!multiple || size==1))</UL>
+</UL>
+<B>OPTION&nbsp;</B>
+<UL>Lives inside the SELECT tag (ignored otherwise).
+<BR>Attributes:
+<UL><B>VALUE</B>=string
+<BR><B>SELECTED</B> boolean</UL>
+</UL>
+<B>TEXTAREA&nbsp;</B>
+<UL>Attributes:
+<UL><B>NAME</B>=string
+<BR><B>ROWS</B>=int (clamped; >= 1)
+<BR><B>COLS</B>=int (clamped; >= 1)
+<BR><B>WRAP</B>= off | hard | soft (default is off; any value which is
+not known turns into soft)</UL>
+</UL>
+<B>KEYGEN&nbsp;</B>
+<UL>Attributes:
+<UL><B>NAME</B>=string
+<BR><B>CHALLENGE</B>=string
+<BR><B>PQG</B>=string
+<BR><B>KEYTYPE</B>=string</UL>
+</UL>
+
+<H3>
+
+<HR ALIGN=LEFT WIDTH="50%"></H3>
+<B>BASEFONT&nbsp;</B>
+<UL>Sets the base font value which +/- size values in FONT tags are relative
+to.
+<BR>Attributes:
+<UL>SIZE=+ int | - int | int (just like FONT)</UL>
+</UL>
+
+<H2>
+
+<HR WIDTH="100%">Unsupported</H2>
+<B>NSCP_CLOSE, NSCP_OPEN, NSCP_REBLOCK, MQUOTE, CELL, SUBDOC, CERTIFICATE,
+INLINEINPUTTHICK, INLINEINPUTDOTTED, COLORMAP, HYPE, SPELL, NSDT</B>
+<UL>These tags are unsupported because they are used internally by netscape
+and are never seen in real content. If somebody does use them between 4.0
+and magellan, tough beans. We never documented them so they lose.</UL>
+
+</BODY>
+</HTML>