diff options
| author | Matt A. Tobin <mattatobin@localhost.localdomain> | 2018-02-02 04:16:08 -0500 |
|---|---|---|
| committer | Matt A. Tobin <mattatobin@localhost.localdomain> | 2018-02-02 04:16:08 -0500 |
| commit | 5f8de423f190bbb79a62f804151bc24824fa32d8 (patch) | |
| tree | 10027f336435511475e392454359edea8e25895d /layout/doc/obsolete | |
| parent | 49ee0794b5d912db1f95dce6eb52d781dc210db5 (diff) | |
| download | UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.gz UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.lz UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.xz UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.zip | |
Add m-esr52 at 52.6.0
Diffstat (limited to 'layout/doc/obsolete')
| -rw-r--r-- | layout/doc/obsolete/block.html | 209 | ||||
| -rw-r--r-- | layout/doc/obsolete/layout-internals.html | 101 | ||||
| -rw-r--r-- | layout/doc/obsolete/layout.css | 124 | ||||
| -rw-r--r-- | layout/doc/obsolete/layout.xml | 279 | ||||
| -rw-r--r-- | layout/doc/obsolete/line-layout.html | 118 | ||||
| -rw-r--r-- | layout/doc/obsolete/nav4-html.html | 902 |
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> + 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> <p>I <b>W</b>as thinking one day</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 "<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> <div> +<br> <p>abc</p> +<br> <p>def</p> +<br> </div> +<p>In the content model for the above html, there is white space between +the various block elements (some after the <div>, some after the first +</p>, again after the second </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> +<h3> +<u>First-line style</u></h3> +First-line is handled entirely by the frame construction code. +<br> +<br> +</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. The parser +creates parser nodes and feeds them to the content sink. The content +sink constructs a content model that represents the hierarchical structure +of the document. As different sub-trees in the content model are +fully available, the stylesheet processor iterates over them and creates +the corresponding frame hierarchy. 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. Block and inline are the two primary display +types specified in CSS and are used in the layout of most of the HTML tags. +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?). +These classes are persistent across reflows and are organized in a hierarchy +to constitute the frame model of the Gecko system. The frame model +is derived by applying style and presentation semantics to the content +model. 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. +The block and inline frame classes implement the nsIFrame and nsIHTMLReflow +interfaces. 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. The nsIHTMLReflow interface +inherits from the nsIReflow interface and adds methods related to word +breaking and whitespace querying. The nsIReflow interface defines +the Reflow() method that initiates the reflow process along with the +DidReflow() method that get calledafter the reflow process. +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. nsBlockReflowContext encapsulates the +state and algorithm for reflowing child block frames. nsBlockReflowState +contains state and methods used by a block frame to reflow itself. +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. Frames get passed in to the +nsLineLayout class via the BeginSpan() and EndSpan() methods. Each +span represents a run of frames with the same style data (???). 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. 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. 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. This is needed because a single +text run can occur on leaves at many levels of the document's content tree. +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. 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> +<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> +<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>"<B>H</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> +<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, 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> /* +<BR> * These tags are special in that, after opening one of +them, all other tags are ignored until the matching +<BR> * closing tag. +<BR> */ +<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 <tr> or <td> tag is seen outside any <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, <table> <table +border> .....,or <table> <tr> <table border>..., the table +will be displayed with border. </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 <table> outside cell +after previous table is flushed out, the new <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 <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 <table> <tr> <tr>, the first <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 '<' sign, it searchs for +'>', observing quoted values. If it cannot find one till EOF, the '<' +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> </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> </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 && <= 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 && <= 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> + <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 && < (windowWidth/2 +- 1)] +<BR><B>MARGINHEIGHT</B>=int [clamped: >= 0 && < (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 < 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 </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 && <= 1000 ] +<BR><B>ROWSPAN</B>=int [clamped: >= 1 && <= 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 ] [clamped: >=1 && <= +7] +<BR><B>POINT-SIZE=</B>[+ int | - int | int ] [clamped: >= 1 && +<= 1600] +<BR><B>FONT-WEIGHT</B>=[+ int | - int | int ] [clamped: >= 100 && +<= 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 < 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> </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 </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 </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 </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> </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 -> " " (2 spaces) +<BR>Note also that the value has newlines stripped from it</UL> +<B>WIDTH</B>=int (clamped >=0 && <= 1000) (only for submit, +reset or button) +<BR><B>HEIGHT</B>=int (clamped >=0 && <= 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 </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 && <= 1000) +<BR><B>HEIGHT</B>= int (clamped >= 0 && <= 1000; only examined +for single entry lists (!multiple || size==1))</UL> +</UL> +<B>OPTION </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 </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 </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 </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> |