Program life 10:20:23 read 937 comments 0 font size: LargeMediumSmall subscription
After analyzing the HTML parsing, we can see a doctor's blog. The structure of WebKit is very sharp, and the Post is as follows:Http://blog.sina.com.cn/s/blog_46d0a3930100d5pt.html
[20] structure and deconstruct of WebKit
It is a complicated process from specifying an HTML text file to drawing a webpage with Complex layout, diverse fonts, and multimedia content including images, audio, and videos. What WebKit does in this process is centered around the DOM tree and rendering tree. In the previous chapter, we talked about the respective functions of these two trees. In this chapter, we use a simple HTML file to demonstrate the specific composition of DOM tree and rendering tree, at the same time, we will take a look at how WebKit constructs these two sequences. Figure 1. from HTML to webpage, and the underlying dom
Tree and rendering tree.
Courtesy http://farm4.static.flickr.com/3351/3556972420_23a30366c2_o.jpg
1. Structure of DOM tree and rendering tree
In Figure 1, a simple HTML text file is displayed on the upper left and a page drawn by WebKit rendering engine on the upper right. The page contains a title, "AI", a line of text, "ape's intelligence", and a photo. The entire page is divided into two layers, the title and the body are drawn at the first layer, and the photo is at the last layer. L Jun and I also followed the process from parsing this HTML text file to generating the DOM tree and rendering tree. The purpose is to understand the specific components of DOM tree and rendering tree, and the construction steps.
Let's talk about the DOM tree in the lower left corner of figure 1. Basically, each tag in an HTML text file corresponds to a class in WebKit, WebCore, and HTML. For example, <HTML> tag corresponds to htmlhtmlelement,
It should be emphasized that the DOM tree is a common data structure. Any XML text file can be translated into a DOM tree, not just HTML text files. In WebKit/WebCore/html, the total HTML classes are basically subclasses of a class in WebKit/WebCore/DOM, that is,/html is a special case of/Dom. This design laid the groundwork for expanding WebKit to layout and rendering of pages other than HTML format in the future. Strictly speaking, the DOM tree in the lower left of Figure 1 is actually an html dom tree.
Looking at the rendering tree, the notable feature is that,
A. The entire rendering TREE tree structure corresponds to the one-to-one html dom tree structure. That is to say, almost all nodes in the html dom tree have corresponding nodes in the rendering tree. The parent-child or sibling relationship between the node and the node is also one-to-one.
The exception is that the html dom tree has an htmlstyleelement leaf node, but there is no corresponding leaf node in the rendering tree. The reason is that each node in the rendering tree involves the layout and rendering of a block area on the page. Htmlstyleelement does not directly involve the layout and rendering of a certain area. The content contained by the htmlstyleelement leaf node in the html dom tree has been incorporated into the attributes of the renderimage leaf node in the rendering tree. In addition, because there is no leaf node corresponding to htmlstyleelement in the rendering tree, the node corresponding to htmlheadelement does not need to exist.
B. Each class in WebKit/WebCore/rendering does not have a one-to-one relationship with HTML tags.
Rendering tree is a general mechanism for planning page layout and rendering. This general mechanism can serve HTML pages, but not only serves HTML pages, we can use the rendering tree to plan the layout and rendering of pages in other formats. A WebKit rendering machine with DOM tree and rendering tree as the core is a powerful and scalable universal rendering machine. It can be used not only to draw HTML pages, but also to render pages in other formats. For example, it can be used to create email reading and manager, database management tools, and even game interfaces.
A little surprising is that for htmlhtmlelement, htmlbodyelement, htmlheadingelement, and htmlparagraphelement, the rendering tree can echo the renderblock. If the difference between htmlheadingelement and htmlparagraphelement is not big, it is only a slight difference between the font and alignment. Therefore, rendering tree can use renderblock for unified response. The problem is that htmlhtmlelement and htmlbodyelement are two types of containers, which always appear in the middle of the DOM tree and never appear as leaf nodes. They correspond to such container nodes, why is rendering tree different from renderblock because it does not have another class? But again, this is not a big problem. It is a matter of beauty at most.
Figure 2. The construction sequence of the root of the DOM tree.
Courtesy http://farm4.static.flickr.com/3010/3554310018_e34d271344_o.jpg
2. root nodes of DOM tree and rendering tree
In the previous section, we mentioned that htmldocument is a special class, which is the root node of the entire html dom tree, but does not correspond to any HTML Tag. The document that often appears in Javascript refers to this root. For example,
HTML text files, usually starting with <HTML> and ending with
At first glance, Figure 2 was a little surprised. When a user opens a blank page in the browser, the DOM tree root node htmldocument and renderview were generated immediately. At this time, the user has not given a URL, that is, for the browser, the specific HTML text file does not exist at this time. The root node is out of line with the specific HTML content, which may imply two design ideas of WebKit,
A. htmldocument, the root node of the DOM tree, And renderview, the root node of the rendering tree, can be reused.
When a user opens two different URLs on the same browser page, that is, two different HTML texts, the two root nodes htmldocument and renderview are not changed, the change is the sub-tree below htmlhtmlelement and the sub-tree of the corresponding rendering tree.
Why is this design? The reason is that htmldocument and renderview are subject to browser page settings, such as the page size and position in the entire screen. These settings have nothing to do with what to display on the page. At the same time, htmldocument is bound to htmltokenizer and htmlparser. These two components are also irrelevant to a specific HTML content.
B. Multiple HTML Subtrees can be hung on the Root Node of the same DOM tree, and multiple renderblock Subtrees can be hung on the Root Node of the same rendering tree.
In the browser we currently see, each page usually only displays one HTML file. Although an HTML file can be divided into multiple frames, each frame carries an independent HTML file, but in terms of the DOM tree structure, there is only one subnode under the htmldocument root node, the child node is htmlhtmlelement, which leads to the Child tree corresponding to an HTML text file. The same is true for the rendering tree. Currently, only one renderview sub-node is available under the root node of the renderview.
However, the WebKit design allows the hanging of Multiple HTML subtree under the same root. Although we have not seen a page with Multiple HTML files and multiple layout and rendering styles, WebKit will leave room for future expansion. The personalization, multi-skin, and multi-view browser page rendering as envisaged in the previous article is not very difficult to implement with WebKit.
Figure 3. The construction sequence of the DOM tree and the rendering tree.
Courtesy http://farm4.static.flickr.com/3627/3554182242_b0bec88534_ B .jpg
3. Construction of DOM tree and rendering tree
The most important component contained in the htmldocument root node is htmltokenizer, and htmltokenizer contains htmlparser. Htmltokenizer reads every character in the HTML text file from the beginning to the end, and extracts each HTML tags and their content. Htmlparser is not only responsible for building HTML Dom trees, but also for building rendering trees.
In step 3, from step 3 to step 3, htmlparser generates an html dom tree node based on an HTML Tag. From step 1 to step 2, generate the corresponding rendering tree node and link it with the html dom tree node. The figure contains too many details and cannot be easily read. Figure 4 demonstrates steps 1 to 2.
Figure 4. An overview of the construction of a DOM tree node and its corresponding rendering Tree node.
Courtesy http://farm4.static.flickr.com/3306/3554259140_3deb9736ea_o.jpg
It is worth noting that when htmlparser generates a DOM tree node, a rendering Tree node is also generated accordingly. Connect the two new nodes. In other words, the rendering tree and DOM tree grow synchronously.
WebKit is appreciated in many ways, but htmlparser's practice of synchronizing DOM tree and rendering tree is questionable. If the data grows synchronously, the rendering tree must be tiled directly and strictly loyal to the DOM tree. Let's assume that we have a DOM tree, then generate a rendering tree, and split the two, so we have the opportunity to make the WebKit play a more fantastic layout and rendering. Although tiled direct flashback is in line with the simultaneous growth of most rendering trees, such layout and rendering are hard to imagine. The reading habits of people most of the time, but the unconventional design also has a market. An example is the multi-viewpoint map at the end of the previous chapter. This layout and rendering are hard to imagine if we want to synchronize the DOM tree with the rendering tree.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
