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 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.
Copyright © 1998