WebCore Rendering III – Layout Basics

Aug 10, 2007

by Dave Hyatt

When renderers are first created and added to the tree, they have no position or size yet. The process by which all of the boxes have their positions and sizes determined is called layout. All renderers have a layout method.

void layout()

Layout is a recursive operation. A class called FrameView represents the containing view for the document, and it also has a layout method. The frame view is responsible for managing the layout of the render tree.

There are two types of layout that the FrameView can perform. The first (and by far the most common) is a layout of the entire render tree. In this case the root of the render tree has its layout method called and then the entire render tree gets updated. The second type of layout is constrained to a specific subtree of the render tree. It is used in situations where the layout of some small subtree can’t possibly affect its surroundings. Right now the subtree layout is only used by text fields (but may be used by overflow:auto blocks and other similar constructs in the future).

The Dirty Bits

Layout uses a dirty bit system to determine whether an object actually needs a layout. Whenever new renderers are inserted into the tree, they dirty themselves and the relevant links in their ancestor chain. There are three unique bits that are used by the render tree.

bool needsLayout() const { return m_needsLayout || m_normalChildNeedsLayout || 
                                  m_posChildNeedsLayout; }
bool selfNeedsLayout() const { return m_needsLayout; }
bool posChildNeedsLayout() const { return m_posChildNeedsLayout; }
bool normalChildNeedsLayout() const { return m_normalChildNeedsLayout; }

The first bit is used when the renderer itself is dirty, and it can be queried using the method selfNeedsLayout. Whenever this bit is set to true, relevant ancestor renderers have bits set indicating that they have a dirty child. The type of bit set depends on the positioned status of the previous link in the chain being dirtied. posChildNeedsLayout is used to indicate that a positioned child got dirtied. normalChildNeedsLayout is used to indicate that an in-flow child got dirtied. By distinguishing between these two types of children, layout can be optimized for the case where only positioned elements moved.

The Containing Block

What exactly did I mean by “the relevant ancestor chain”? When an object is marked as needing layout, the ancestor chain that is dirtied is based on a CSS concept called the containing block. The containing block is also used to establish the coordinate space of children. Renderers have xPos and yPos coordinates, and these are relative to their containing blocks. So what exactly is a containing block?

Here is the CSS 2.1 spec’s introduction to the concept.

My own way of introducing the concept in terms of the WebCore render tree would be as follows:

A renderer’s containing block is an ancestor block of the renderer that is responsible for determining that renderer’s position.

In other words when layout recurs down the render tree, it is a block’s responsibility to position all of the renderers that have it as their containing block.

The root of the render tree is called the RenderView, and this class corresponds to the initial containing block according to CSS2.1. It is also the renderer that will be returned if the renderer() method is called on the Document.

RenderView.h

The initial containing block is always sized to the viewport. In desktop browsers, this is the visible area in the browser window. It is also always at position (0,0) relative to the entire document. Here’s a picture illustrating where the initial containing block is positioned for a document. The black bordered box represents the RenderView, and the grey box represents the entire document.

If the document is scrolled, then the initial containing block will be moved offscreen. It is always at the top of the document and sized to the viewport. One area of confusion that people often have with the initial containing block is that they expect it to somehow be outside the document and part of the viewport.

Here is the detailed containing block specification in CSS2.1.

The rules can be summarized as follows:

  • The root element’s renderer (i.e., the <html> element) will always have the RenderView as its containing block.
  • If a renderer has a CSS position of relative or static, then the containing block will be the nearest block-level ancestor in the render tree.
  • If a renderer has a CSS position of fixed, then the containing block will be the RenderView. Technically the RenderView does not act as a viewport, so the RenderView has to adjust the coordinates of fixed positioned objects to account for the document scroll position. It is simpler to just let the RenderView act like a viewport containing block for this one case rather than having a separate renderer just for the viewport.
  • If a renderer has a CSS position of absolute, then the containing block is the nearest block-level ancestor with a position other than static. If no such ancestor exists, then the containing block will be the RenderView.

The render tree has two convenience methods for asking if an object has a position of absolute, fixed or relative. They are:

bool isPositioned() const;   // absolute or fixed positioning
bool isRelPositioned() const;  // relative positioning

Throughout most of the code the term positioned refers to both absolute and fixed positioned objects in CSS. The term relPositioned refers to relative positioned objects in CSS.

The render tree has a method for obtaining the containing block of a renderer.

RenderBlock* containingBlock() const

When an object is marked as needing layout, it walks up a container chain setting either the normalChildNeedsLayout bit or the posChildNeedsLayout bit. The isPositioned status of the previous link in the chain determines what bit gets set. The container chain roughly corresponds to the containing block chain, although intermediate inlines are still dirtied as well. A different method called container is used instead of containingBlock to determine the chain for dirtying because of this distinction.

RenderObject* container() const

layoutIfNeeded and setNeedsLayout(false)

The layoutIfNeeded method (similar in terminology to AppKit’s displayIfNeeded method) is a convenient shorthand for telling a renderer to only do a layout if it has a dirty bit set.

void layoutIfNeeded()

All layout methods typically end with setNeedsLayout(false). It is important to clear dirty bits on the renderer before leaving the layout method, so that future layout calls won’t mistakenly think that the object is still dirty.

Anatomy of a Layout Method

At a high level layout methods usually look something like this:

void layout()
{
    ASSERT(needsLayout());

    // Determine the width and horizontal margins of this object.
    ...

    for (RenderObject* child = firstChild(); child; child = child->nextSibling()) {
        // Determine if the child needs to get a relayout despite the dirty bit not being set.
        ...

        // Place the child.
        ...

        // Lay out the child
        child->layoutIfNeeded();

       ...
    }

    // Now the intrinsic height of the object is known because the children are placed
    // Determine the final height
    ...

    setNeedsLayout(false);
}

We will drill into specific layout methods in future articles.