WebCore can be divided into two principal areas: KWQ and KHTML.
KWQ - KWQ (pronounced "quack") is an adapter layer used to communicate with KHTML. It is written in Objective C++. The KHTML engine used in Konqueror was written on top of a cross-platform toolkit called Qt. KWQ is essentially an implementation of the subset of Qt required to make KHTML work on OS X. KWQ files can be found under the "kwq" subdirectory.
KHTML - KHTML is the layout engine and contains all of the code for constructing and rendering HTML and XML. This code is written entirely in C++, with the exception of some glue code that communicates with WebKit (using Objective C++). In general, code inside the "khtml" subdirectory is designed to be given back to KDE unless that code is contained in a .mm file (signifying Objective C++ code) or is contained inside #if APPLE_CHANGES.
When you see APPLE_CHANGES in the code, then we have deviated from KHTML to solve some problem unique to OS X, and it makes no sense for those changes to be used when building KHTML on other platforms.
The "khtml" directory contains only seven subdirectories. They are as follows:
Consider the following HTML document:
<html><head><style>p { color: red }</style></head><body><p>Hello world.</p></body></html>
Let's follow the construction of this document from parsing through to the final rendering on screen. From WebCore's perspective, the action starts in an object called the KHTMLPart. The KHTMLPart is a container object that houses the current document, its JS objects, its render tree, and its stylesheets.
The begin method creates the appropriate document (HTML vs. XML) based off the MIME type sent by the Web server.
The document creates an object called an HTMLTokenizer whose implementation can be found in khtml/html/htmltokenizer.cpp. The tokenizer's job is to scan the bytes sent from the network and construct tokens out of the source. For example it figures out when you have an open tag or a close tag, or what kinds of attributes go with a specific tag.
The tokenizer in turn creates a KHTMLParser. The implementation of the parser can be found in khtml/html/htmlparser.cpp. The parser's job is to take the tokens it receives from the HTML tokenizer and build DOM nodes. The entire construction of the DOM tree for an HTML document happens from within the parser.
When the parser encounters stylesheets such as the one contained in the example above, it creates an instance of a CSS parser to build up a CSS object model for the rules, declarations and selectors contained in the sheet. The implementation of the CSS parser can be found in khtml/css/cssparser.cpp.
As sheets complete construction, they are added to the document. The parsing of a sheet does not delay the construction of the DOM tree by the parser, unless the sheet is contained inline inside the HTML (as in the example above).
As soon as style information becomes available (i.e., all stylesheets have loaded and been attached to the document), style information will be computed for each element. This method, called styleForElement, can be found in khtml/css/cssstyleselector.cpp. This method examines all of the stylesheets in the document and it constructs a RenderStyle object that contains all of the computed style information for a given element in terms that are easily accessible to the render tree.
Once the style information has been computed, if a corresponding rendering object should be constructed, then that render object is built and the style object is attached to the render object (and owned by the render object).
The process of building RenderObjects and RenderStyles for elements is called attachment. Similarly the destruction of said objects is called detachment. All DOM implementation objects have an attach() method that is called recursively to build up the render tree, and a detach method that is called to destroy the render tree.
Once the render tree has been built, it must receive a layout. RenderObjects implement a layout method that is used to determine the position and size of the RenderObject boxes on screen. Layout is a recursive function, so calling layout on the root RenderObject results in the entire rendering tree being flowed.
Finally once all of the rendering objects have been placed at the correct positions, they are painted. All RenderObjects implement paint methods. Painting is also recursive.
So to summarize, the steps involved in building up a document are:
联系客服