Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2025-02-04 04:58:00 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Moved these files to new subfolder 'obsolete'

Browse Source
This commit is contained in:
attinasi%netscape.com 2002-01-16 01:20:39 +00:00
parent 3e780ab9d9
commit 365de153e1
6 changed files with 0 additions and 1709 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

205
layout/doc/block.html
View File

@ -1,205 +0,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>
Floater 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>Floater Management</u></h3>
Since child block elements are containing blocks for floaters, the only
place where a block frame will see a floater is as part of an inline line.
Consequently, the nsLineBox will only keep track of floaters on inline
lines (saving storage for block lines).
<p>The nsLineLayout class and the block frame cooperate in the management
of floaters. Since the frame construction code leaves a "placeholder" frame
in-flow where the floater was found, when nsLineLayout reflows a placeholder
frame it knows to inform the block about it. That triggers the blocks "AddFloater"
logic which then determines where the floater 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 floaters,
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
floater. To simplify this process, the spacemanager is used to keep track
of available and busy space. Floaters 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>

97
layout/doc/layout-internals.html
View File

@ -1,97 +0,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 nsHTMLContainerFrame (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 WillReflow()
and DidReflow() methods that get called before and after the reflow process
respectively.&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 nsHTMLContainerFrame?
<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 floaters, anonymous
blocks, etc.</li>
</ol>
</body>
</html>

120
layout/doc/layout.css
View File

@ -1,120 +0,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-botom: .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;
}

275
layout/doc/layout.xml
View File

@ -1,275 +0,0 @@
<?xml version="1.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
"Floater-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, floaters, 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>

114
layout/doc/line-layout.html
View File

@ -1,114 +0,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, floater breaks, etc. Currently, we only support
line breaks, and floater 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 seperate inline elements.
<p>As a post-processing step, the TrimTrailingWhiteSpace logic is used
to remove those pesky pices 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>

898
layout/doc/nav4-html.html
View File

@ -1,898 +0,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 seperates 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 ingored) 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 compatability. 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 coments now, need to add quoeted 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 alighment 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; seperate 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>