layout/doc/obsolete/layout-internals.html@97036ab72558 (annotated)
layout/doc/obsolete/layout-internals.html
Tue, 06 Jan 2015 21:39:09 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Tue, 06 Jan 2015 21:39:09 +0100
- branch
- TOR_BUG_9701
- changeset 8
- 97036ab72558
- permissions
- -rw-r--r--
Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.
| michael@0 | 1 | <!-- This Source Code Form is subject to the terms of the Mozilla Public |
| michael@0 | 2 | - License, v. 2.0. If a copy of the MPL was not distributed with this |
| michael@0 | 3 | - file, You can obtain one at http://mozilla.org/MPL/2.0/. --> |
| michael@0 | 4 | |
| michael@0 | 5 | <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| michael@0 | 6 | <html> |
| michael@0 | 7 | <head> |
| michael@0 | 8 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| michael@0 | 9 | <meta name="Author" content="Nisheeth Ranjan"> |
| michael@0 | 10 | <meta name="GENERATOR" content="Mozilla/4.5 [en]C-NSCP (WinNT; U) [Netscape]"> |
| michael@0 | 11 | <title>HTML Layout Internals</title> |
| michael@0 | 12 | </head> |
| michael@0 | 13 | <body> |
| michael@0 | 14 | |
| michael@0 | 15 | <h1> |
| michael@0 | 16 | HTML Layout Internals</h1> |
| michael@0 | 17 | |
| michael@0 | 18 | <h2> |
| michael@0 | 19 | Big picture</h2> |
| michael@0 | 20 | An HTML document comes in from netlib into the HTML parser. The parser |
| michael@0 | 21 | creates parser nodes and feeds them to the content sink. The content |
| michael@0 | 22 | sink constructs a content model that represents the hierarchical structure |
| michael@0 | 23 | of the document. As different sub-trees in the content model are |
| michael@0 | 24 | fully available, the stylesheet processor iterates over them and creates |
| michael@0 | 25 | the corresponding frame hierarchy. The frames recursively layout |
| michael@0 | 26 | and render themselves. |
| michael@0 | 27 | <p>The part that we are going to drill down into is the code in the block |
| michael@0 | 28 | and inline frame classes. Block and inline are the two primary display |
| michael@0 | 29 | types specified in CSS and are used in the layout of most of the HTML tags. |
| michael@0 | 30 | The table related tags have their own display types like "table-cell", |
| michael@0 | 31 | "table-row", etc. and their implementation is a separate topic in itself. |
| michael@0 | 32 | <h2> |
| michael@0 | 33 | Block and inline code</h2> |
| michael@0 | 34 | The main classes involved in the layout of HTML documents are nsBlockFrame |
| michael@0 | 35 | and nsInlineFrame, both of which inherit from nsContainerFrame (why?). |
| michael@0 | 36 | These classes are persistent across reflows and are organized in a hierarchy |
| michael@0 | 37 | to constitute the frame model of the Gecko system. The frame model |
| michael@0 | 38 | is derived by applying style and presentation semantics to the content |
| michael@0 | 39 | model. Each frame in the frame model has a one to one correspondence |
| michael@0 | 40 | with a rectangular region on the presentation context (screen, printer, |
| michael@0 | 41 | etc.) and contains the formatting information needed to render that rectangle. |
| michael@0 | 42 | The block and inline frame classes implement the nsIFrame and nsIHTMLReflow |
| michael@0 | 43 | interfaces. The nsIFrame interface contains methods for managing |
| michael@0 | 44 | child frames and linkage with sibling frames, accessing the style context |
| michael@0 | 45 | associated with the frame, painting the frame, and handling events that |
| michael@0 | 46 | are passed in from the widget hierarchy. The nsIHTMLReflow interface |
| michael@0 | 47 | inherits from the nsIReflow interface and adds methods related to word |
| michael@0 | 48 | breaking and whitespace querying. The nsIReflow interface defines |
| michael@0 | 49 | the Reflow() method that initiates the reflow process along with the WillReflow() |
| michael@0 | 50 | and DidReflow() methods that get called before and after the reflow process |
| michael@0 | 51 | respectively. nsReflowState and nsReflowMetrics are parameters to |
| michael@0 | 52 | the templatized nsIReflow interface: the former is used to hold state during |
| michael@0 | 53 | reflow of a frame and the latter is used to return the frame's desired |
| michael@0 | 54 | size and alignment to the parent frame during the reflow process. |
| michael@0 | 55 | <p>nsBlockReflowContext and nsBlockReflowState both hold state information |
| michael@0 | 56 | during the reflow process. nsBlockReflowContext encapsulates the |
| michael@0 | 57 | state and algorithm for reflowing child block frames. nsBlockReflowState |
| michael@0 | 58 | contains state and methods used by a block frame to reflow itself. |
| michael@0 | 59 | Both these classes are instantiated once per block frame. |
| michael@0 | 60 | <p>The nsLineLayout class is the engine used by the block and inline frame |
| michael@0 | 61 | classes to layout themselves on a line. Frames get passed in to the |
| michael@0 | 62 | nsLineLayout class via the BeginSpan() and EndSpan() methods. Each |
| michael@0 | 63 | span represents a run of frames with the same style data (???). Other |
| michael@0 | 64 | methods exist on the nsLineLayout class to position and size the frames |
| michael@0 | 65 | on the current line. |
| michael@0 | 66 | <p>nsBlockBandData is the class used to manage the processing of the space-manager |
| michael@0 | 67 | (nsSpaceManager) band data. It provides HTML/CSS specific semantics |
| michael@0 | 68 | on top of the general space management facilities provided by nsSpaceManager. |
| michael@0 | 69 | <p>nsSpaceManager is a class that is told about regions that reserve space |
| michael@0 | 70 | and exposes methods to query for available space in a given band. |
| michael@0 | 71 | <p>The nsLineBox class represents a horizontal line of frames and is singly |
| michael@0 | 72 | linked to the next line box in the document. It is basically a container |
| michael@0 | 73 | of a frame list that share the property of being on the same line in the |
| michael@0 | 74 | formatted output of the document. |
| michael@0 | 75 | <p>The nsTextRun class holds on to a list of frames containing pieces of |
| michael@0 | 76 | text that form a logical text run. This is needed because a single |
| michael@0 | 77 | text run can occur on leaves at many levels of the document's content tree. |
| michael@0 | 78 | This class gives the text layout process an efficient way to get access |
| michael@0 | 79 | to text runs and, so, determine where word breaks should occur. |
| michael@0 | 80 | <h2> |
| michael@0 | 81 | Questions</h2> |
| michael@0 | 82 | What are anonymous blocks (nsBlockFrame.h)? |
| michael@0 | 83 | <br>What is the difference between a span and a band (nsLineLayout)? |
| michael@0 | 84 | <br>Why do nsBlockFrame and nsInlineFrame both inherit from nsContainerFrame? |
| michael@0 | 85 | <h2> |
| michael@0 | 86 | To Do</h2> |
| michael@0 | 87 | |
| michael@0 | 88 | <ol> |
| michael@0 | 89 | <li> |
| michael@0 | 90 | Provide more information about methods and state of each of the classes |
| michael@0 | 91 | above.</li> |
| michael@0 | 92 | |
| michael@0 | 93 | <li> |
| michael@0 | 94 | Give a description of how the above classes interact with each other as |
| michael@0 | 95 | a simple HTML document is laid out. Then, add in different features |
| michael@0 | 96 | to the HTML that exercise different areas of the code, like floats, anonymous |
| michael@0 | 97 | blocks, etc.</li> |
| michael@0 | 98 | </ol> |
| michael@0 | 99 | |
| michael@0 | 100 | </body> |
| michael@0 | 101 | </html> |
