# Gecko Layout Detailed Design Document Template

[Use this template to start your detailed design. Replace items in square brackets with the appropriate text for your component, class or system. Keep in mind that this is just a general template intended for most designs. Your specific design may require different organization or topics - the goal is to provide detailed information about the software to the reader.]

# [Component / Class Name] Detailed Design

## Overview

[Introduce the scope of this design document: what is being documented here. Provide a reference back to the High Level design(s) that correspond.]

## [Class / Component A]

[Briefly refresh the reader with the purpose of the class or component. Provide enough information to make accessible the following sections on the public API, private methods and members, and algorithms. Bring up and tricky or otherwise interesting relationships that will be detailed.]

### Public API

[Show the public API for the component, as IDL, C++ header file, or as a pseudo-code description. If using a source file, the comments in the source file should cover most of the detail needed. If they do not, then add that detail there. See the Overview document for more details on the scope of information that should be presented.]

### Protected API

[If there is a protected API, list the methods and members and indicate the responsibilities of the callers with respect o calling the base class, enforcing base class invariants, etc.]

### Implementation Notes

[The nasty details of the implementation get exposed here. This section can be broken down into subsections as necessary, and should include details of particularly important algorithms, performance characteristics or constraints, memory usage, tricky ownership issues, and anything else that would make understanding the implementation easier for the reader.]

#### Algorithms

##### [Interesting Algorithm 1: The internally maintained sorted list]

[explain the nature of the algorithm, the reason it was chosen, the types of input it is expected to operate on, etc. Annotated pseudo-code is a good idea here, but actual code is often too detailed to b of much use by itself. It the actual code is sufficient to understand it, then this subsection is probably not needed.]

##### [Interesting Algorithm 2: Handling overflow of the input buffer]

[your description here]

####

## [Class / Component B]

[Repeat the structure for the next class or component.]

## Cross-Component Algorithms

[specify the details of algorithms that cross a single component. refer to each component, describe the flow of control, the responsibilities of each component along the way, the error handling, the state-management if any, and the expected results for a given input. Generally each of these algorithms gets its own subsection.]

### [Turning a byte-stream into a fully parsed token-tree]

[Detailed description, pesudo-code, state transitions, etc.]

### [Managing updates to the document]

[Detailed description, pesudo-code, state transitions, etc.]

## Tech Notes

[This section contains links to tech notes related to the implementations covered in this design. Tech Notes tend to be extremely specific, often recipes for how to do something or how to fix a class of defects. If the tech note is more general, it may be a good idea to move it into the Detailed design itself.]

- [Debugging buffer overflows ]
- [Adding new element or attribute types ]
- [How To detect and fix problems with the alignment of elements ]
- [Fix for Bug 666: ownership of tokens was mistakenly transferred ]