Layout Module Description

Evolution of the HTML Layout Module

This is a history, in four phases, of HTML layout in Communicator.

Rectangles, Linked Lists, and Lines

At first, HTML was parsed and tokenized. A stream of tokens was fed to layout. Although some tokens (such as <B>) changed the internal state, the goal was to create a list of objects, each of which controlled a rectangular piece of screen real estate. Objects were basic things such as Text, Image, Form Element, and List bullet.

The objects were laid out left to right and top to bottom to fill a page. The were also connected in a doubly linked list that in essence represented the entire document.

To simplify access to the middle of the list, there was also an array of lines. Each element in the line array pointed to the leftmost item on that line in the linked list.

Floating Objects and Wrapped Text

With the advent of images that could be wrapped by text, a new linked list was added. This new list was distinct from the doubly linked element list that made up a page. These new objects would drop down to the nearest opening in the left or right margin and insert themselves there. In response either the left margin moved right, or the right margin moved left, or both. There was, and always has been, a bug caused by objects dropped next to the margin that are wider than the entire page and overlap in some way. The lines could still be laid out left to right and top to bottom, but they just threaded between the block objects in the margins. Because the floating objects were in a separate list, the Find and Select commands do not operate correctly on them.

Tables: Nested documents and nested document state

At its simplest, a table cell is just a complete HTML document restricted to a smaller rectangular area in the larger document. At its most complex, a table can be extremely difficult to manage.

Tables are sized dynamically during multiple attempts. The cell is laid out several times at different sizes before all cells can be displayed at their final sizes. Netscape never implemented incremental layout of page sections, so the document state was split up and most of it used to simulate a cell as a nested HTML document. The existing layout code could then be used to simulate the layout of that cell multiple times until the size was right.

This process was slow and wasteful of memory. Multiple attempts to optimize and streamline made the code difficult to read and never really solved the problem of less than optimal memory use and speed.

Layers

Layers solve the overlap problem. In the first phase of HTML layout, all elements were rectangles, allowing only "blocky" documents. However, layers allow overlap with controlled transparency and greater design possibilities.