diff --git a/layout/doc/block.html b/layout/doc/block.html deleted file mode 100644 index b31bc69fc43e..000000000000 --- a/layout/doc/block.html +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - - - -

-Block Layout

-This document attempts to describe how "block" layout works in the mozilla -layout engine. -

nsBlockFrame implements layout behavior that conforms to the -CSS "display:block" and "display: list-item" layout. It has several responsibilities: -

    -
  1. - 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.
    2. - -
  2. -Floater management. The block is responsible for the reflow and placement -of floating elements.
    3. - -
  3. -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.
    4. - -
  4. -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!
    5. -
- -

-The Big Picture for Block Reflow

-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: -
"inline" lines which contain only inline elements -
"block" lines which contain exactly one block element
-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 as if the line had been reflowed. This -saves time and allows for a faster incremental reflow. For lines which -are dirty, the line is reflowed appropriately. -

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. -

Here is a list of the various classes involved in block layout: -

nsBlockFrame -

The primary culprit.
-nsBlockReflowState -
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.
-nsBlockBandData -
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.
-nsBlockReflowContext -
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).
-nsLineBox -
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.
-nsLineLayout -
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).
-nsTextRun -
This is a data class used to store text run information. Text -runs are logically 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.
- -

-Frame construction methods

-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". -

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". -

-Line Layout

-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. -

The helper class nsLineLayout provides the majority of the line layout -behavior needed by the block. -

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>I <b>W</b>as thinking one day</p> -

Notice that the word "Was" is composed of two pieces of text, and that -they do not 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. -

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. -

-Floater Management

-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). -

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). -

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. -

-Child Block Placement

-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 after -the top margin is computed. Hence, there is some unfortunate duplication -of reflow state calculations present in the block frame code. -

-Bullets

-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. -

-Blank lines

-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: -

  <div> -
   <p>abc</p> -
   <p>def</p> -
  </div> -

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>). -

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. -

-First-letter style

-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. -

There are two things different that the block does: -

It is responsible for calling nsLineLayout::SetFirstLetterStyleOK -
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. -
  -

-First-line style

-First-line is handled entirely by the frame construction code. -
  -
  - - diff --git a/layout/doc/layout-internals.html b/layout/doc/layout-internals.html deleted file mode 100644 index 93f614c850c8..000000000000 --- a/layout/doc/layout-internals.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - - HTML Layout Internals - - - -

-HTML Layout Internals

- -

-Big picture

-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. -

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. -

-Block and inline code

-The main classes involved in the layout of HTML documents are nsBlockFrame -and nsInlineFrame, both of which inherit from nsHTMLContainerFrame (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 WillReflow() -and DidReflow() methods that get called before and after the reflow process -respectively.  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. -

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. -

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. -

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. -

nsSpaceManager is a class that is told about regions that reserve space -and exposes methods to query for available space in a given band. -

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. -

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. -

-Questions

-What are anonymous blocks (nsBlockFrame.h)? -
What is the difference between a span and a band (nsLineLayout)? -
Why do nsBlockFrame and nsInlineFrame both inherit from nsHTMLContainerFrame? -

-To Do

- -
    -
  1. -Provide more information about methods and state of each of the classes -above.
    2. - -
  2. -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 floaters, anonymous -blocks, etc.
    3. -
- - - diff --git a/layout/doc/layout.css b/layout/doc/layout.css deleted file mode 100644 index 3a385b05e4d2..000000000000 --- a/layout/doc/layout.css +++ /dev/null @@ -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; -} - diff --git a/layout/doc/layout.xml b/layout/doc/layout.xml deleted file mode 100644 index 986c9812b049..000000000000 --- a/layout/doc/layout.xml +++ /dev/null @@ -1,275 +0,0 @@ - - - - - - -Gecko Layout Engine -Troy Chevalier -8 August 1999 - -Overview -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. - -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. - -Components -Here are a list of components and terms that will be referenced by this document. - - -Parser -Either the HTML -or XML parser. Processes the document and makes calls to the content sink. - -Content sink -Called by the parser. Responsible for building the content model. - -Content model -Consists of document object and a tree of content objects. Changes to the -content model result in modifications of the frame model. - -Frame model -Frames are formatting -objects. Each frame defines a particular set of formatting characteristics. - -Reflow -The formatting process. Reflow of the frame model defines the visual appearance -of the formatted document. - -Frame construction -Initial creation and updating of the frame model in response to changes to the -content model and changes to the style data. - -Style system -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. - -Presentation shell -Controlling point for managing the presentation of a document. - -View system -Consists of a view manager and view objects arranged in a tree hierarchy. -Views support overlapped positioning, z-order sorting, and opacity levels. - - -Document Loading -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. - -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 - -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. - - - -The actual interfaces involved are: - -nsIDocument -nsIDocumentObserver -nsIPresShell -nsIStyleSet -nsIStyleFrameConstruction -nsIFrame - - - -All of the interface files are located in the mozilla/layout/base/public -directory. - -Object Lifetimes -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. - -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. - -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. - -Frames -Each frame defines a particular set of formatting characteristics. Frames have -the opportunity to: - -reflow (format) their child frames -render their appearance -handle mouse and keyboard events -display a cursor -have an associated view object - - - -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. - -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. - -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. - -Frame Construction -The frame construction process begins with a notification that content -has been added or removed or that style has changed. - -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). - -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. - -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". - -Frame Manager -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: - -provides a service for mapping from content object to frame and from out-of-flow -frame to placeholder frame -coordinates structural modifications to the frame model - - - -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. - -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. - -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. - -Reflow Process -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. - -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. - -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. - -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. - -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. - -In addition to the computed values for the CSS box model properties, the -following items are also included: - -reflow reason that indicates why the frame is being reflowed -a rendering context that can be used to measure text -reflow command (only used for incremental reflow) -space manager - - - -The most common reflow reasons are 'eReflowReason_Resize' (the viewport -has changed size) and 'eReflowReason_Incremental' (processing of an incremental -reflow command). - -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). - -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. - -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. - -Frame Classes -There are four main categories of frame classes, all of which are located -in mozilla/layout/html/src: - - -core frame classes -table frame classes -form frame classes -frameset frame classes - - - -The core frame classes implement the CSS viewport abstraction, scrolling, -block and inline display of flowed elements, floaters, and absolute positioning. - -For more information on block layout, click -here. For more information about -line layout, click here. - -The table frame classes 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. - -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. - -Event Manager -To be written - - diff --git a/layout/doc/line-layout.html b/layout/doc/line-layout.html deleted file mode 100644 index e1405dc8ddd7..000000000000 --- a/layout/doc/line-layout.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - - - -

-Line Layout

-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. -

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. -

Line layout as a process contains the following steps: -

    -
  1. -Initialize the nsLineLayout object (done in nsBlockFrame). This prepares -the line layout engine for reflow by initializing its internal data structures.
    2. - -
      -
  2. -Reflowing of inline frames. The block code uses nsLineLayout's ReflowFrame -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.
    3. - -


    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. -
      -

  3. -Finish line layout by vertically aligning the frames, horizontally aligning -the frames and relatively positioning the frames on the line.
    4. -
-nsLineLayout is also used by nsBlockFrame to construct text-run information; -this process is independent of normal line layout is pretty much a hack. -

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: -

-The handling of the reflow status is done by the container frame using -nsLineLayout. -

-Line Breaking

-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). -

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>H</B>ello -there" is breakable after the "o" in "ello" but not after -the "H"), 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. -

-White-space

-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. -

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. -

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. -

-Vertical Alignment

-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. -

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 -
(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. -
  -

-Horizontal Alignment

-After all frames on a line have been placed vertically, the block code -will use nsLineLayout to perform horizontal alignment within the extra -space. - - diff --git a/layout/doc/nav4-html.html b/layout/doc/nav4-html.html deleted file mode 100644 index b3a4cf0b0756..000000000000 --- a/layout/doc/nav4-html.html +++ /dev/null @@ -1,898 +0,0 @@ - - - - - - HTML - - - - -

-HTML

-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. -

-Parsing

-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: - -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: - - -

-Tag Processing

-Tags are processed by the parser by locating a "tag handler" 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. -

-Special Hacks

-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. - -TODO: - -List of 6.0 features incompatible with 4.0 - - -
-

-Tags (Categorically sorted)

-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. - -

divalign = left | right | center | justify -
alignparam = abscenter | left | right | texttop | absbottom -| baseline | center | bottom | top | middle | absmiddle -
colorspec = named-color | #xyz | #xxyyzz | #xxxyyyzzz | #xxxxyyyyzzzz -
clip = [auto | value-or-pct-xy](1..4) (pct of width for even -coordinates; pct of height for odd coordinates) -
value-or-pct = an integer with an optional %; ifthe percent -is present any following characters are ignored! -
coord-list = XXX -
whitespace-strip = remove leading and -trailing and any embedded whitespace that is not an actual space (e.g. -newlines) -

-Head objects:

-TITLE - -BASE - -META - -LINK - -HEAD - -HTML - -STYLE - -FRAMESET - -FRAME - -NOFRAMES - - -

- -
Body objects:

- BODY - -LAYER, ILAYER - -NOLAYER - -P - -ADDRESS - -PLAINTEXT, XMP - -LISTING - -PRE - -NOBR - -CENTER - -DIV - -H1-H6 - -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. -

- -

-TABLE - -TR - -TH, TD - -CAPTION - -MULTICOL - - -

- -

-BLOCKQUOTE - -UL, OL, MENU, DIR - -DL - -LI - -DD - -DT - - -

- -

-A - -STRIKE, S, TT, CODE, SAMPLE, KBD, B, STRONG, I, EM, VAR, CITE, BLINK, -BIG, SMALL, U, INLINEINPUT, SPELL - -SUP, SUB - -SPAN - -FONT - -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. -

- -

-text, entities - -IMG, IMAGE - -HR - -BR - -WBR - -EMBED - -NOEBMED - -APPLET - -PARAM - -OBJECT - -MAP - -AREA - -SERVER - -SPACER - - -

- -

-SCRIPT - -NOSCRIPT - - -

- -

-FORM  - -ISINDEX  - -INPUT  - -SELECT  - -OPTION  - -TEXTAREA  - -KEYGEN  - - -

- -

-BASEFONT  - - -

- -
Unsupported

-NSCP_CLOSE, NSCP_OPEN, NSCP_REBLOCK, MQUOTE, CELL, SUBDOC, CERTIFICATE, -INLINEINPUTTHICK, INLINEINPUTDOTTED, COLORMAP, HYPE, SPELL, NSDT - - - -