Rendering Static Content

2.5.2 Rendering Static Content

When a layout engine renders a web site, it goes through a series of processes as illustrated in figure 2.2. In the figure, the light-blue rectangles are the processes, and the green boxes are data structures. In the following sections, each of the processes, and the data that they generate, will be described in more details. The Parser and Content Sink processes are con- sidered as one process in the following description The description is based on documentation from Mozilla[46][47].

Figure 2.2: Rendering process in Mozilla Firefox. The figure is created by L. David Baron from the Mozilla Corporation for a presentation of Mozilla’s Layout Engine[46].

Parser

The layout engine takes the source document as input, and parses it into acontent model, which is implemented as a tree structure. In the content model, each element from the source document is represented as a node. In the implementation of the layout engine, there is one data type for each possible DOM element. And each node in the content model has the data type that corresponds to the DOM element it represents. It is the content model which can later be accessed through the DOM interface methods, which will be described in more details later in section 2.5.3.

CSS parser

During the parsing of the source document, all CSS style attributes on elements and embed- ded style rules are passed to the CSS parser, as illustrated by the dashed line in the figure. The CSS parser then parses this styling information, together with any external style sheets attached to the document. The parsing of all the CSS styling information results in a set ofstyle rules.

Frame constructor

The frame constructor uses the content model and the style rules to create a frame tree, which is a tree of rectangular formatting primitives. Each rectangular formatting primitive represents a content node and thereby one of the elements from the source document. Later, the reflow process of the layout engine uses the frame tree and the formatting primitives in it, to decide how each of the content nodes should be positioned in relation to each other.

Before the frame tree is created, astyle context is created for each node in the content model. A style context represents style data for a formatting primitive. The style data consists of a list of CSS properties and their values.

To create a style context for a node in the content model, the style context of the parent node in the content model is needed, together with style data defined by style rules for the current content node. In the following list, it is described why the data is needed and how it is accessed.

Parent style context: The style context of the parent node in the content model is needed,

as some CSS properties, if not defined for the current node, should inherit the value of the parent node. Examples of this are the CSS properties “font” and “color”. Astyle context tree, which has the same structure as the content model, contains all the style context data that have been created for each node. This style context tree is used to get the style context of the parent node. As each node uses the style context of the parent node to create its own style context, the style context data are created for the elements in the content model in a top-down manner.

Style data: Besides the styling from the parent content node, a content node can of course

be styled by style data in style rules, so this data is needed. To get the style data defined specific by style rules for the content node, the following is performed: All the parsed style rules are iterated through with the most specific rule first (as defined by the CSS cascade). For each of the style rules, it is then tested whether the selector of the style rule matches the content node. All the style rules where this is the case, are then used to compute the style data. To compute the style data, the style data from all the style rules are added to a style struct, with the style data from the most specific rule first. It is not possible for a style rule to add style data for a property that has already been set by a more specific style rule.

Now that the parent style context and the style data defined by style rules are known, it is possible to create the style context for the current content node. This is done by combining the style data in the context style of the parent content node and the style data defined by the style rules. If there are any conflicting properties, then the ones defined by the style data in the style rules are used.

The process of creating the style context for each content node is, as seen in the above description, a time-consuming process. But it has been optimized in various ways:

Hash tables: To decrease the time used to find style rules that match a content node, hash

tables have been used. The indices used in the hash tables are tag name, ID and class name. So it is quick to find style rules that match a content node, if the selectors in the style rules use tag name, ID or class name.

Rule tree: To avoid iterating through all the style rules for each content node, the result