Bottom-layer knowledge of WEB Front-end: How browsers work (4)-Render tree and CSS Parsing

While constructing the DOM Tree, the browser is also constructing another-Render Tree, which should be called the Render Tree as opposed to the DOM Tree for the moment, we know that the DOM tree provides some column access interfaces (DOM APIs) for javascript, but this tree is not external. Its main function is to display HTML in a certain layout and style, and use relevant CSS knowledge. From the MVC perspective, we can regard the render tree as V, the dom tree as M, and C as the specific dispatcher, such as HTMLDocumentParser.

　　New ConceptRender tree

Every node in the Render tree is called renderer or render object. Looking at the source code of WEBKIT, we can find that Renderer is a basic class definition, which is the base class of all renderer objects.

class RenderObject{    virtual void layout();    virtual void paint(PaintInfo);    virtual void rect repaintRect();    Node* node;  //the DOM node    RenderStyle* style;  // the computed style    RenderLayer* containgLayer; //the containing z-index layer}

From this, we can find that renderer contains a dom object and its calculated style rules, providing layout and display methods. Details: (Frames in firefox corresponds to renderers and content corresponds to dom)

　　

In specific display, each renderer represents a rectangular block, that is, the concept of the CSS box model. It contains some geometric attributes, such as width and width, height, position, and so on. Each renderer has a very important attribute, that is, how to display it and display it. We know that there are many display types of elements. The common ones are none, inline, block, inline-block.... What are the differences between different display types? Let's take a look at the Code:

　　

RenderObject* RenderObject::createObject(Node* node, RenderStyle* style){    Document* doc = node->document();    RenderArena* arena = doc->renderArena();    ...    RenderObject* o = 0;    switch (style->display()) {        case NONE:            break;        case INLINE:            o = new (arena) RenderInline(node);            break;        case BLOCK:            o = new (arena) RenderBlock(node);            break;        case INLINE_BLOCK:            o = new (arena) RenderBlock(node);            break;        case LIST_ITEM:            o = new (arena) RenderListItem(node);            break;       ...    }    return o;}

For more details, see the WEBKIT source code. The above only lists the snippets.

　　DOM tree and Render tree

　　In this case, there is no Render tree without the DOM tree, but they are not a simple one-to-one relationship. We already know that the render tree is used for display. Invisible elements will not appear in this tree, for example,

 

It is very rich with DOM object types, such as head, title, div, and Render tree. After all, it is used for display rendering in the future. We can also see that some DOM elements do not have the corresponding renderer, while some DOM elements correspond to several renderer, which is common for multiple renderer, to solve the problem that renderer cannot clearly describe how to display, for example, the select element requires three renderer, one for the display area, one for the drop down list box and one for the button.

There is also a relationship that we can see, that is, the location of the renderer and dom elements may be different. The elements added with float: ETC or position: absolute are constructed based on their actual locations when constructing the Render tree because they are separated from the normal Document Stream order.

　　The DOM tree may be updated at any time, not limited to the parsing phase, such as $ elment. append or $ elment. addClass, we can see that the page is refreshed immediately, and the browser handles this situation. We know the root node of the Dom tree is doument. The root node of the Render tree may have different names in different browsers. webkit calls it RenderView and firefox calls it ViewPortFrame.

CSS Parsing

　　All the terms used by CSS are defined as follows:

?

comment     \/\*[^*]*\*+([^/*][^*]*\*+)*\/ num     [0-9]+|[0-9]*"."[0-9]+ nonascii    [\200-\377] nmstart     [_a-z]|{nonascii}|{escape} nmchar      [_a-z0-9-]|{nonascii}|{escape} name        {nmchar}+ ident       {nmstart}{nmchar}*

Note: ident indicates the class in the style, and name indicates the id in the style.

The syntax BNF format used by CSS is defined as follows:

?

ruleset   : selector [ ',' S* selector ]*     '{' S* declaration [ ';' S* declaration ]* '}' S*   ; selector   : simple_selector [ combinator selector | S+ [ combinator selector ] ]   ; simple_selector   : element_name [ HASH | class | attrib | pseudo ]*   | [ HASH | class | attrib | pseudo ]+   ; class   : '.' IDENT   ; element_name   : IDENT | '*'  ; attrib   : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*     [ IDENT | STRING ] S* ] ']'  ; pseudo   : ':' [ IDENT | FUNCTION S* [IDENT S*] ')' ]   ;

Style Calculation

　　For each HTML element, we may define many different types of styles, such as fonts, colors, and la S. Even if the element is not defined by us, the browser or user personality settings will also create some styles for it by default.

Style calculation is an extremely complex process. We can set styles for a batch of elements in a similar way when defining styles, but when parsing and constructing renderer, the browser defines each construction style. We may have defined many styles and different rules. It is very difficult to find the style rules for element matching. The browser has multiple algorithm errors to implement computation. The specific analysis is not detailed. An element may eventually match many style rules after computation, and there is a certain priority between them, from low to high:

1. Default browser Style
2. Customized browser settings
3. General HTML style defined by the developer
4. Defined by HTML developers! Important Style
5. Customize browser settings for users! Important Style

　　More detailed Priority Calculation Formula

• Count 1 if the declaration is from is a 'style' attribute rather than a rule with a selector, 0 otherwise (=)
• Count the number of ID attributes in the selector (= B)
• Count the number of other attributes and pseudo-classes in the selector (= c)
• Count the number of element names and pseudo-elements in the selector (= d)

Specific visible http://www.w3.org/TR/CSS2/cascade.html#specificity

Example

* {}/* A = 0 B = 0 c = 0 d = 0-> specificity = 0, 0, 0 */li {}/* a = 0 B = 0 c = 0 d = 1-> specificity = 0, 0, 1 */li: first-line {}/* a = 0 B = 0 c = 0 d = 2-> specificity = 0, */ul li {}/* a = 0 B = 0 c = 0 d = 2-> specificity =, 0, 2 */ul ol + li {}/* a = 0 B = 0 c = 0 d = 3-> specificity = 0, */h1 + * [rel = up] {}/* a = 0 B = 0 c = 1 d = 1-> specificity =, */ul ol li. red {}/* a = 0 B = 0 c = 1 d = 3-> specificity = 0, 0, 1, 3 */li. red. level {}/* a = 0 B = 0 c = 2 d = 1-> specificity = 0, 0, 2, 1 */# x34y {}/* a = 0 B = 1 c = 0 d = 0-> specificity = 0, 1, 0, 0 */style = ""/* a = 1 B = 0 c = 0 d = 0-> specificity = */

Layout
After the style rules of the renderer are determined above, the layout of the important display factors is displayed. After the renderer is constructed and added to the render tree, it does not have the location and size information. The process of determining the information for it is called layout. HTML uses a layout model of stream layout. The layout is arranged from top to bottom, from left to right. The layout starts from the root node of the render tree, the initial position of the document node corresponding to the dom tree is 0, 0. The detailed layout process is as follows: the width of each renderer is determined by the renderer of the parent node. The parent node traverses the child node, determines the position (x, y) of the child node, and calls the layout method of the child node to determine its height. The parent node determines its own height based on the height, margin, and padding of the child node.

To avoid the re-construction of the overall layout of the entire page due to DOM modification or style change in a small area, the browser adopts a dirty bit system technology, make it as much as possible to change the layout of the element itself or its child elements. Of course, in some cases, it is inevitable to reconstruct the layout of the entire page. For example, changes to the overall style affect all renderer, such as body {font-size: the font size of 111px} has changed, and the browser window has been adjusted to resize.
For the interface design, the most difficult part of a page should be the layout, with a lot of content. We will explain it below.