1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/layout/doc/dd-template.html Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,116 @@
1.4 +<!-- This Source Code Form is subject to the terms of the Mozilla Public
1.5 + - License, v. 2.0. If a copy of the MPL was not distributed with this
1.6 + - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
1.7 +
1.8 +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
1.9 +<html>
1.10 +<head>
1.11 +
1.12 + <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
1.13 + <title>Layout Detailed Design Template</title>
1.14 + <meta name="author" content="Marc Attinasi (attinasi@netscape.com)">
1.15 +</head>
1.16 + <body>
1.17 +
1.18 +<h1><font color="#cc0000">Gecko Layout Detailed Design Document Template</font></h1>
1.19 + [Use this template to start your detailed design. Replace items in square
1.20 + brackets with the appropriate text for your component, class or system. Keep
1.21 + in mind that this is just a general template intended for most designs.
1.22 +Your specific design may require different organization or topics - the
1.23 +goal is to provide detailed information about the software to the reader.]<br>
1.24 + <br>
1.25 +
1.26 +<h1>[Component / Class Name] Detailed Design</h1>
1.27 +
1.28 +<h2>Overview</h2>
1.29 + [Introduce the scope of this design document: what is being documented here.
1.30 +Provide a reference back to the High Level design(s) that correspond.]<br>
1.31 +
1.32 +<hr width="100%" size="2">
1.33 +<h2>[Class / Component A]</h2>
1.34 + [Briefly refresh the reader with the purpose of the class or component.
1.35 +Provide enough information to make accessible the following sections on the
1.36 +public API, private methods and members, and algorithms. Bring up and tricky
1.37 +or otherwise interesting relationships that will be detailed.]<br>
1.38 + <br>
1.39 +
1.40 +<h3>Public API</h3>
1.41 + [Show the public API for the component, as IDL, C++ header file, or as a
1.42 +pseudo-code description. If using a source file, the comments in the
1.43 +source file should cover most of the detail needed. If they do not, then add
1.44 +that detail there. See the Overview document for more details on the
1.45 +scope of information that should be presented.]<br>
1.46 +
1.47 +<h3>Protected API</h3>
1.48 + [If there is a protected API, list the methods and members and indicate
1.49 +the responsibilities of the callers with respect o calling the base class,
1.50 +enforcing base class invariants, etc.]<br>
1.51 + <br>
1.52 +
1.53 +<h3>Implementation Notes</h3>
1.54 + [The nasty details of the implementation get exposed here. This section
1.55 +can be broken down into subsections as necessary, and should include details
1.56 +of particularly important algorithms, performance characteristics or constraints,
1.57 +memory usage, tricky ownership issues, and anything else that would make understanding
1.58 +the implementation easier for the reader.]<br>
1.59 +
1.60 +<h4>Algorithms</h4>
1.61 +
1.62 +<h5>[Interesting Algorithm 1: The internally maintained sorted list]</h5>
1.63 + [explain the nature of the algorithm, the reason it was chosen, the types
1.64 +of input it is expected to operate on, etc. Annotated pseudo-code is a good
1.65 +idea here, but actual code is often too detailed to b of much use by itself.
1.66 +It the actual code is sufficient to understand it, then this subsection is
1.67 +probably not needed.]<br>
1.68 +
1.69 +<h5>[Interesting Algorithm 2: Handling overflow of the input buffer]</h5>
1.70 + [your description here]<br>
1.71 +
1.72 +<h4></h4>
1.73 +
1.74 +<hr width="100%" size="2">
1.75 +<h2>[Class / Component B]</h2>
1.76 + [Repeat the structure for the next class or component.]<br>
1.77 + <br>
1.78 +
1.79 +<hr width="100%" size="2">
1.80 +<h2>Cross-Component Algorithms</h2>
1.81 + [specify the details of algorithms that cross a single component. refer
1.82 +to each component, describe the flow of control, the responsibilities of each
1.83 +component along the way, the error handling, the state-management if any,
1.84 +and the expected results for a given input. Generally each of these algorithms
1.85 +gets its own subsection.]<br>
1.86 +
1.87 +<h3>[Turning a byte-stream into a fully parsed token-tree]</h3>
1.88 + [Detailed description, pesudo-code, state transitions, etc.]<br>
1.89 +
1.90 +<h3>[Managing updates to the document]</h3>
1.91 + [Detailed description, pesudo-code, state transitions, etc.]<br>
1.92 + <br>
1.93 +
1.94 +<hr width="100%" size="2">
1.95 +<h2>Tech Notes</h2>
1.96 + [This section contains links to tech notes related to the implementations
1.97 +covered in this design. Tech Notes tend to be extremely specific, often
1.98 +recipes for how to do something or how to fix a class of defects. If
1.99 +the tech note is more general, it may be a good idea to move it into the Detailed
1.100 +design itself.]<br>
1.101 +
1.102 +<ul>
1.103 + <li>[<a href="link%20to%20tech%20note">Debugging buffer overflows</a>
1.104 + ]</li>
1.105 + <li>[<a href="link%20to%20tech%20note">Adding new element or attribute
1.106 +types</a>
1.107 + ]</li>
1.108 + <li>[<a href="link%20to%20tech%20note">How To detect and fix problems
1.109 +with the alignment of elements</a>
1.110 + ]</li>
1.111 + <li>[<a href="link%20to%20tech%20note">Fix for Bug 666: ownership of tokens
1.112 +was mistakenly transferred</a>
1.113 + ]</li>
1.114 +
1.115 +</ul>
1.116 + <br>
1.117 +
1.118 +</body>
1.119 +</html>
