| blob | 475ed50cf48ac76850b89fbbd2558f63b0c9a247 |
2 <html>
3 <head>
7 </head>
8 <body>
10 <br>
12 Layout is primarily concerned with providing a presentation to an HTML or
13 XML document. This presentation is typically formatted in accordance with
16 the W3C. Presentation formatting is also required to provide compatibility
17 with legacy browsers (Microsoft Internet Explorer and Netscape Navigator
18 4.x). The decision about when to apply CSS-specified formatting and when
19 to apply legacy formatting is controlled by the document's DOCTYPE specification.
20 These layout modes are referred to as 'Standards' and 'NavQuirks' modes. (DOCTYPE
21 and modes are explained in more detail <a
23 <br>
24 The presentation generally is constrained by the width of the window in which
25 the presentation is to be displayed, and a height that extends as far as
26 necessary. This is referred to as the Galley Mode presentation, and is what
27 one expects from a typical browser. Additionally, layout must support a paginated
28 presentation, where the width of the presentation is constrained by the dimensions
29 of the printed output (paper) and the height of each page is fixed. This
30 paged presentation presents several challenges not present in the galley
31 presentation, namely how to break up elements that are larger than a single
32 page, and how to handle changes to page dimensions.<br>
33 <br>
34 The original design of the Layout system allowed for multiple, possibly different,
35 presentations to be supported simultaneously from the same content model.
36 In other words, the same HTML or XML document could be viewed as a normal
37 galley presentation in a browser window, while simultaneously being presented
38 in a paged presentation to a printer, or even an aural presentation to a
39 speech-synthesizer. To date the only real use of this multiple presentation
40 ability is seen in printing, where multiple presentations are managed, all
41 connected to the same content model. (note: it is unclear if this is really
42 a benefit - it may have been better to use a copy of the content model for
43 each presentation, and to remove the complexity of managing separate presentations
44 - analysis is needed here). The idea of supporting a non-visual presentation
45 is interesting. Layout's support for aural presentations is undeveloped,
46 though conceptually, it is possible and supported by the architecture.<br>
47 <br>
49 So, layout is concerned with providing a presentation, in galley or paged
50 mode. Given a content model, how does the layout system actually create the
51 presentation? Through the creation and management of frames. Frames are an
52 encapsulation of a region on the screen, a region that contains geometry
53 (size and location, stacking order). Generally frames correspond to the content
54 elements, though there is often a one-to-many correspondence between content
55 elements and frames. Layout creates frames for content based on either the
56 specific HTML rules for an element or based on the CSS display type of the
57 element. In the case of the HTML-specific elements, the frame types that
58 correspond to the element are hard-coded, but in the more general case where
59 the display type is needes, the layout system must determine that display
60 type by using the Style System. A content element is passed to the Style
61 System and a request is made to resolve the style for that element. This
62 causes the Style System to apply all style rules that correspond to the element
63 and results in a resolved Style Context - the style data specific to that
64 element. The Layout module looks at the 'display' field of the style context
65 to determine what kind of frame to create (block, inline, table, etc.). The
66 style context is associated with the frame via a reference because it is
67 needed for many other computations during the formatting of the frames.<br>
68 <br>
69 Once a frame is created for a content element, it must be formatted. We refer
70 to this as 'laying out' the frame, or as 'reflowing' the frame. Each frame
71 implements a Reflow method to compute its position and size, among other
72 things. For more details on the Reflow mechanism, see the Reflow Overview
73 document... The CSS formatting requirements present two distinct layout
74 models: 1) the in-flow model, where the geometry of an element is influenced
75 by the geometry of the elements that precede it, and 2) the positioned model,
76 where the geometry of an element is not influenced by the geometry of the
77 elements that precede it, or in any case, is influenced more locally. The
78 in-flow cased is considered the 'normal' case, and corresponds to normal
79 HTML formatting. The later case, called 'out of flow' puts the document author
80 in control of the layout, and the author must specify the locations and sizes
81 of all of the elements that are positioned. There is, of course, some complexity
82 involved with managing these two models simultanelusly...<br>
83 <br>
84 So far the general flow of layout looks like this:<br>
85 <br>
87 2) Utilize the Style System to resolve the style of each element in the content
88 model<br>
89 3) Construct the frames that correspond to the content model, according to
90 the resolved style data.<br>
91 4) Perform the initial layout, or initial reflow, on the newly constructed
92 frame.<br>
93 <br>
94 This is pretty straight-forward, but is complicated somewhat by the notion
96 is to create parts of the presentation as they become available, rather than
97 waiting for the entire document to be read, parsed, and then presented. This
98 is a major benefit for large documents because the user does not have to wait
99 for the 200th page of text to be read in before the first page can be displayed
100 - they can start reading something right away. So really, this sequence of
101 operations Resolve Style, Create Frame, Layout Frame, gets repeated many
102 times as the content becomes available. In the normal in-flow case this is
103 quite natural because the sequential addition of new content results in sequential
104 addition of new frames, and because everything is in-flow, the new frames
105 do not influence the geometry of the frames that have already been formatted.
106 When out-of-flow frames are present this is a more difficult problem, however.
107 Sometimes a content element comes in incrementally, and invalidates the formatting
108 of some of the frames that precede it, frame that have already been formatted.
109 In this case the Layout System has to detect that impact and reflow again
111 <br>
113 dynamic changes to the content model, changes that occur after the document
114 has been loaded and (possibly) presented. These dynamic changes are caused
117 through java script). When a content element is modified, added or removed,
118 Layout is notified. If content elements have been inserted, new frames are
119 created and formatted (and impacts to other frames are managed by performing
120 further incremental reflows). If content is removed, the corresponding frames
121 are destroyed (again, impacts to other elements are managed). If a content
122 element is modified, layout must determine if the chage influences the formatting
123 of that or other elements' presentations, and must then reformat, or re-reflow,
124 the impacted elements. In all cases, the determination of the impact is critical
125 to avoid either the problem of not updating impacted elements, thus presenting
126 an invalid presentation, or updating too much of the presentation and thus
127 doing too much work, potentially causing performance problems.<br>
128 <br>
129 One very special case of dynamic content manipulation is the HTML Editor.
130 Layout is used to implement both a full-blown WYSIWYG HTML editor, and a single
131 and multi-line text entry control. In both cases, the content is manipulated
132 by the user (via the DOM) and the resulting visual impacts must be shown as
133 quickly as possible, without disconcerting flicker or other artifacts that
134 might bother the user. Consider a text entry field: the user types text into
135 a form on the web. As the user types a new character it is inserted into
136 the content model. This causes layout to be notified that a new piece of
137 content has been entered, which causes Layout to create a new frame and format
138 it. This must happen very fast, so the user's typing is not delayed. In the
139 case of the WYSIWYG HTML editor, the user expects that the modifications
140 they make to the document will apear immediately, not seconds later. This
141 is especially critical when the user is typing into the document: it would
142 be quite unusable if typing a character at the end of a document in the HTML
143 editor caused the entire document to be reformated - it would be too slow,
144 at least on low-end machines. Thus the HTML editor and text controls put
145 considerable performance requirements on the layout system's handling of dynamic
146 content manipulation.<br>
148 There are many types of frames that are designed to model various formatting
149 requirements of different HTML and XML elements. CSS2 defines several (block,
150 inline, list-item, marker, run-in, compact, and various table types) and
151 the standard HTML form controls require their own special frame types to
152 be formatted as expected. The most essential frame types are Block and Inline,
153 and these correspond to the most important Layout concepts, the Block and
154 Line.<br>
155 <br>
156 A block is a rectangular region that is composed of one or more lines. A
157 line is a single row of text or other presentational elements. All layout
158 happens in the context of a block, and all of the contents of a block are
159 formatted into lines within that block. As the width of a block is changed,
160 the contents of the lines must be reformatted. consider for example a large
161 paragraph of text sitting in paragraph:<br>
162 <br>
164 on Mozilla. If you write your own code, document it. Much of the
166 things out, try and document your discoveries.
169 of lines of text that correspond to the text. As the width of the block changes
170 (due to the window being resized, for example) the length of the lines within
171 it changes, and thus more or less text appears on each line. The block is
172 responsible for managing the lines. Note that lines may contain only inline
173 elements, whereas block may contain both inline elements and other blocks.<br>
175 In addition to managing CSS-defined formatting, the layout system provides
176 a way to integrate other layout schemes into the presentation. Currently
177 layout supports the formatting of XUL elements, which utilize a constraint-based
178 layout language. The Box is introduced into the layout system's frame model
179 via an adapter (BoxToBlockAdapter) that translates the normal layout model
180 into the box formatting model. Conceptually, this could be used to introduce
181 other layout systems, but it might be worth noting that there was no specific
182 facility designed into the layout system to accommodate this. Layout deals
183 with frames, but as long as the layout system being considered has no need
184 to influence presentational elements from other layout systems, it can be
185 adapted using a frame-based adapter, ala XUL.<br>
186 <br>
188 At the highest level, the layout system is a group of classes that manages
189 the presentation within a fixed width and either unlimited height (galley
190 presentation) or discrete page heights (paged presentation). Digging just
191 a tiny bit deeper into the system we find that the complexity (and interest)
192 mushrooms very rapidly. The idea of formatting text and graphics to fit within
193 a given screen area sounds simple, but the interaction of in-flow and out-of-flow
194 elements, the considerations of incremental page rendering, and the performance
195 concerns of dynamic content changes makes for a system that has a lot of
196 work to do, and a lot of data to manage. Here are the high-level classes
197 that make up the layout system. Of course this is a small percentage of the
198 total clases in layout (see the detailed design documents for the details
199 on all of the classes, in the context of their actual role).<br>
201 Together the presentation shell and the presentation context provide the
202 root of the current presentation. The original design provided for a single
203 Presentation Shell to manage multiple Presentation Contexts, to allow a single
204 shell to handle multiple presentations. It is unclear if this is really possible,
205 however, and in general it is assumed that there is a one-to-one correspondence
206 between a presentation shell and a presentation context. The two classes
207 should probably be folded into one, or the distinction between them formalized
208 and utilized in the code. The Presentation Shell currently owns a controlling
209 reference to the Presentation Context. Further references to the Presentation
210 Shell and Presentation Context will be made by using the term Presentation
211 Shell.<br>
212 <br>
213 The Presentation Shell is the root of the presentation, and as such it owns
214 and manges a lot of layout objects that are used to create and maintain a
216 of the Presentation Shell, and in some cases the creator of the objects
217 used by the Presentation Shell to manage the presentation. More details
218 of the Document Viewer are needed here...</font>). The Presentation Shell,
219 or PresShell, is first and foremost the owner of the formatting objects,
220 the frames. Management of the frames is facilitated by the Frame Manager,
221 an instance of which the PresShell owns. Additionally, the PresShell provides
222 a specialized storage heap for frames, called an Arena, that is used to make
223 allocation and deallocation of frames faster and less likely to fragment
224 the global heap. <br>
225 <br>
226 The Presentation Shell also owns the root of the Style System, the Style
227 Set. In many cases the Presentation Shell provides pass-through methods to
228 the Style Set, and generally uses the Style Set to do style resolution and
229 Style Sheet management.<br>
230 <br>
231 One of the critical aspects of the Presentation Shell is the handling of
232 frame formatting, or reflow. The Presentation Shell owns and maintains a
233 Reflow Queue where requests for reflow are held until it is time to perform
234 a reflow, and then pulled out and executed.<br>
235 <br>
236 It is also important to see the Presentation Shell as an observer of many
237 kinds of events in the system. For example, the Presentation Shell receives
238 notifications of document load events, which are used to trigger updates
239 to the formatting of the frames in some cases. The Presentation Shell also
240 receives notifications about changes in cursor and focus states, whereby
241 the selection and caret updates can be made visible.<br>
242 <br>
243 There are dozens of other data objects managed by the Presentation Shell
244 and Presentation Context, all necessary for the internal implementation.
245 These data members and their roles will be discussed in the Presentation
246 Shell design documents. For this overview, the Frames, Style Set, and Reflow
247 Queue are the most important high-level parts of the Presentation Shell.<br>
249 The Frame Manager is used to, well, manage frames. Frames are basic formatting
250 objects used in layout, and the Frame Manager is responsible for making frames
251 available to clients. There are several collections of frames maintained
252 by the Frame Manager. The most basic is a list of all of the frames starting
253 at the root frame. Clients generally do not want to incur the expense of
254 traversing all of the frames from the root to find the frame they are interested
255 in, so the Frame Manager provides some other mappings based on the needs of
256 the clients.<br>
257 <br>
258 The most crucial mapping is the Primary Frame Map. This collection provides
259 access to a frame that is designated as the primary frame for a piece of
260 content. When a frame is created for a piece of content, it may be the 'primary
261 frame' for that content element (content elements that require multiple
262 frames have primary and secondary frames; only the primary frame is mapped).
263 The Frame Manager is then instructed to store the mapping from a content
264 element to the primary frame. This mapping facilitates updates to frames
267 <br>
268 Another important mapping maintained by the Frame Manager is that of the
269 undisplayed content. When a content element is defined as having no display
270 (via the CSS property 'display:none') it is noted by a special entry in the
271 undisplayed map. This is important because no frame is generated for these
272 elements yet changes to their style values and to the content elements still
273 need to be handled by layout, in case their display state changes from 'none'
274 to something else. The Undisplayed Map keeps track of all content and style
276 the original architecture of the layout system included the creation of frames
277 for elements with no display. This changed somewhere along the line, but
278 there is no indication of why the change was made. Presumably it is more
279 time and space-efficient to prevent frame creation for elements with no display.)</font><br>
280 <br>
281 The Frame Manager also maintains a list of Forms and Form Controls, as <i>content
282 nodes</i>. This is presumably related to the fact that layout is responsible
283 for form submission, but this is a design flaw that is being corrected by
284 moving form submission into the content world. These collections of Forms
285 and Form Controls should be removed eventually.<br>
286 <br>
288 The Frame Constructor is responsible for resolving style values for content
289 elements and creating the appropriate frames corresponding to that element.
290 In addition to managing the creation of frames, the Frame Constructor is
291 responsible for managing changes to the frames. Frame Construction is generally
292 achieved by the use of stateless methods, but in some cases there is the
293 need to provide context to frames created as children of a container. The
294 Frame Manager uses the Frame Constructor State class to manage the important
295 information about the container of a frame being created (<font
299 The Frame is the most fundamental layout object. The class nsFrame is the
300 base class for all frames, and it inherits from the base class nsIFrame (note:
301 nsIFrame is NOT an interface, it is an abstract base class. It was once an
302 interface but was changed to be a base class when the Style System was modified
303 - the name was not changed to reflect that it is not an interface). The Frame
304 provides generic functionality that can be used by subclasses but cannot
305 itself be instantiated.<br>
306 <br>
307 nsFrame:<br>
308 The Frame provides a mechanism to navigate to a parent frame as well as child
309 frames. All frames have a parent except for the root frame. The Frame is
310 able to provide a reference to its parent and to its children upon request.
311 The basic data that all frames maintain include: a rectangle describing the
312 dimensions of the frame, a pointer to the content that the frame is representing,
313 the style context representing all of the stylistic data corresponding to
314 the frame, a parent frame pointer, a sibling frame pointer, and a series
315 of state bits.<br>
316 <br>
317 Frames are chained primarily by the sibling links. Given a frame, one can
318 walk the sibling of that frame, and can also navigate back up to the parent
319 frame. Specializations of the frame also allow for the management of child
320 frames; this functionality is provided by the Container Frame.<br>
321 <br>
322 Container Frames:<br>
323 The Container Frame is a specialization of the base frame class that introduces
324 the ability to manage a list of child frames. All frames that need to manage
325 child frames (e.g. frames that are not themselves leaf frames) derive from
326 Container Frame.<br>
327 <br>
328 <br>
329 <br>
331 </h3>
334 </h3>
336 </h3>
339 <br>
340 <br>
343 </b>
344 <ul>
346 to general layout concepts, links to relevant specs and existing documents.<br>
347 </li>
348 </ul>
349 </body>
350 </html>