You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.
The details of block and line layout are tricky; this document serves as a ``cheat sheet'' that describes how the vagary of different state flags control what's going on. It's a work-in-progress, with questions in red italics. If you know the answer, please pass it along to me so I can update the document.
This section presents some of the classes involved in block and line reflow, along with important members of each object that control reflow processing.
The base class for all frames.
Flags set on the frame to indicate its state. These flags can be grouped into two categories: flags which affect all frames (``public'' flags), and flags that are reserved for an individual frame's private use (``private'' flags).
This bit is set when the frame is being actively being reflowed.
By default it is set in WillReflow(), and unset in
DidReflow(). Many frames' Reflow()
method verifies that the bit is set with an assertion.
This flag is set on a newly created frame, and later cleared by
the frame's Reflow() method when the frame has had
its inital reflow.
This flag is set if the combined area of a frame's children
extend past the frame's bounding box.
(What is a frame's ``bounding
box''?)
If this flag is set, then
mOverflowArea
will contain the total area of the frame, including the overflow.
An unflowable frame is an error condition; for example, due
to system limitations. Currently, the only way to get an
unflowable frame is to have a frame tree that is ``too
deep''. (See
nsFrame::IsFrameTreeTooDeep().)
These flags are the private flags that are meaningful to block frames.
Causes the block to ``shrink-wrap'' around its content. This means the block will determine its children's width and make its content area that wide. Finally, it will add padding and border to determine the final width.
Is this where the ``tending towards zero width'' stuff comes in?
Indicates that this is a frame from which child margins can
be calculated. The absence of this flag implies that child
margin calculations should ignore the frame and look further
up the parent chain. Used in
nsBlockReflowContext::ComputeCollapsedTopMargin().
This flag causes the nsBlockReflowState's constructor to set
the BRS_ISTOPMARGINROOT and
BRS_ISBOTTOMMARGINROOT flags.
This is set by default for document, table cell inner, and absolutely positioned wrapper frames.
This indicates that a block frame should create its own space manager. This is required by each block frame that can contain floaters: the space manager is used to reserve space for the floated frames.
This is set by default for document frames, area frames, table cell inner frames, absolutely positioned wrapper frames, and floated frames when the frame is created.
A block consists of lines and other blocks, stacked vertically. A
block frame has one nsLineBox for each line, and one
nsLineBox for each block child. These are stored as
a doubly-linked list in the mLines member of
nsBlockFrame.
The current state of reflow, built up as reflow recursively descends the frame tree. This is ``passed in'' to a child frame from its parent, and provides the constraints in which the child frame must size itself; e.g. the width and height available to the child frame.
Given the current container frame and the style applied to the child, these values are the resolved values for the child frame's box.
The structure that is ``filled in'' by a frame during reflow, and is used to communicate the frame's desired size information back to its container.
The maximum width that the frame would consume if it were reflowed with an unconstrained available width. It might be better named ``preferred width''.
This is computed when the nsBlockReflowState flag
BRS_COMPUTEMAXWIDTH is set.
The maximum width for elements within the frame that cannot be broken down further; e.g., the longest word in a paragraph. Note that an out-of-flow frame (e.g., a floater) may affect this value.
This field is a pointer to an nsSize object. When
null, the frame need not compute it.
Additional reflow state information that the block frame uses along
with nsHTMLReflowState. Like
nsHTMLReflowState, this is read-only data that is
passed down from a parent frame to its children.
This flag is set in the nsBlockReflowState
constructor when:
nsHTMLReflowState, and
NS_UNCONSTRAINEDSIZE as its available width in
the nsHTMLReflowState.
This flag is set in the nsBlockReflowState
constructor when the frame being reflowed has been given
NS_UNCONSTRAINEDSIZE as its available height in
the nsHTMLReflowState.
If set, NS_UNCONSTRAINEDSIZE is passed to
nsLineLayout as the available height.
Related to BRS_SHRINKWRAPWIDTH. Set if we need
to force a resize reflow when computing the final size.
e.g., because...why?
This flag is set in nsBlockFrame::Reflow() if we
detect that we're incrementally reflowing a linebox that
contains inline frames. In this case, we can avoid some of
the work that occurs during reflow.
This flag is set in the nsBlockReflowState
constructor when the ``white-space'' style of the
block frame is pre or nowrap. It is
cleared, otherwise.
This flag is set in the nsBlockReflowState
constructor when reflowing a ``block margin root''
frame (i.e., a frame with the NS_BLOCK_MARGIN_ROOT
flag set, for which margins apply by default).
The flag is also set when reflowing a frame whose computed top border padding is zero. (why?)
This flag is set in the nsBlockReflowState
constructor when reflowing a ``block margin root''
frame (i.e., a frame with the
NS_BLOCK_MARGIN_ROOT flag set, for which margins
apply by default).
The flag is also set when reflowing a frame whose computed bottom border padding is zero. (why?)
This flag is set if the top margin should be considered when
placing a linebox that contains a block frame. It may be set
as a side-effect of calling
nsBlockFrame::ShouldApplyTopMargin(); once set,
ShouldApplyTopMargin() uses it as a fast-path way
to return whether the top margin should apply.
If the flag hasn't been set in the block reflow state, then
ShouldApplyTopMargin() will crawl the line list
to see if a block frame precedes the specified frame. If so,
the top margin should be applied, and the flag set to cache
the result. (If not, the top margin will be applied as a
result of the generational margin collapsing logic in
nsBlockReflowContext::ComputeCollapsedTopMargin(). In
this case, the flag won't be set, so subsequent calls
to ShouldApplyTopMargin() will continue crawl the
line list.)
This flag is also set in the nsBlockReflowState
constructor if BRS_ISTOPMARGINROOT is set; that
is, if the frame being reflowed is a margin root by default.
This flag is set if reflow should recompute an element's maximum size.
It is set in the nsBlockReflowState constructor
if the ``maxElementSize'' member of the
nsHTMLReflowMetrics object has been provided by
(the parent frame?).
This flag is set if reflow should recompute a frame's maximum
width; for example, during first-pass table reflow. When this
is set, nsBlockFrame::ReflowLine will flow the
first line and each unwrapped line in the block
twice.
Encapsulates the transient reflow state for a
nsLineBox that contains a block frame.
During an incremental reflow, this member holds current frame in the reflow chain.
Encapsulates the transient reflow state for a
nsLineBox that contains inline frames. A new
nsLineLayout object is created for each inline
linebox that is flowed.
true by default when starting line layout.
(Why isn't this just stored in the frame?)
In nsLineLayout, a ``span'' is a container inline
frame, and a ``frame'' is one of its children. Perhaps PerParentData and
PerChildData would be better names?
nsLineLayout::BeginLineReflow creates the initial
PerSpanData which is called the ``root span''.
nsInlineFrame::ReflowFrames creates a new
PerSpanData when it calls
nsLineLayout::BeginSpan: at this time, the
nsLineLayout object's mCurrentSpan is
switched to the new span. The new span records the old
mCurrentSpan as its parent.
After reflowing the child inline frames,
nsInlineFrame::ReflowFrames calls
nsLineLayout::EndSpan, which pops the
PerSpanData and re-sets mCurrentSpan.
The first PerFrameData structure in the span.
The last PerFrameData structure frame in the
span. PerFrameData structures are added to the
span as they are reflowed.
mLastFrame may also be directly manipulated if a
line is split, or if frames are pushed from one line to the
next.
The PerFrameData of the inline frame that ``owns''
the span, or null if this is the root span.
mFrame is initialized to the containing inline
frame's PerFrameData when a new
PerSpanData is pushed in
nsLineLayout::BeginSpan.