In an earlier article I wrote, that in designing a style sheet
language we first have to talk about three things:
ADDRESSING: the `left hand side' of the style rules; specifies
what part of a doc is affected by a rule
FEATURES: what aspects of a design can be specified (font size,
color, frames, alignment, background, etc.)
MODEL: feature semantics are defined relative to a conceptual
model (e.g. TeX's boxes & glue, DSSSL's flow-objects)
Some thoughts on addressing are contained in
<http://info.cern.ch/hypertext/WWW/Style/mail/bb-9-nov-94.html>. Below
I'll try to formulate a model of formatting. [As before, I'll add my
personal preference in square brackets.]
A model for style sheets is in fact a model of a formatted document,
and maybe also of the formatting process itself. Like all models,
this one will chunk together several features and ignore many
details.
DYNAMIC/STATIC
One reason why the formatting process itself might be modeled, is
the fact that the retrieval of a document can be seen as a dynamic
process. When the source document is stored locally, it is not a
problem to assume that the whole of it is available at once. But
when a network is involved, we might want to define a process that
works on the data in the order that it arrives.
[I have a slight preference for the dynamic model, despite the
restrictions that it will likely impose on the layout. Netscape has
shown the desirability of such a dynamic -- and interruptible --
process.]
CHUNKING
A formatted page can be seen as a 2D surface (or 2.5D, if we allow a
cascade of windows or popups), filled with smaller areas. Areas can
be chunked in several ways:
- small (letters, words) or larger (paragraphs, headers, tables)
- nested or not
- rectangular or arbitrarily shaped, maybe even disconnected
- tightly packed or sparse (with constraints or `stretchable glue')
The size and shape of an area is determined by internal (bottom up)
and external (top down) factors:
- letter sizes lead to sizes for words, paragraphs, etc.
- the page or window has a certain size, constraining its contents
- some dimensions are user-settable (margin, indent, line spacing)
In this view, the `formatted document' is basically a static,
geometric figure. But on-line `formatting' doesn't need to result in
a 2D surface. It can also be used to generate speech, or text that
moves smoothly from bottom to top, like the titles at the end of a
movie. But if we try to design a language that has all these
possibilities, we might well end up with a language that is
essentially a general purpose programming language and not something
that the average user can apply.
PAPER VS ON-LINE
On-line presentation differs from paper-based layout not only in the
visual aspects (less detail, more color, blinking), but also in the
fact that on-line presentation *can* be (inter-) active. Interactive
aspects include:
- zoom in/out
- fold/unfold
- pop up
- hyperlinking
- scrolling of sub-regions
- forms: text fields, menus, buttons, drawing areas, etc.
The style sheet language we are looking for will primarily be used
for on-line display. Maybe documents can have different style sheets
(in different languages?) for different purposes: a high quality,
slow style sheet for printing, and a simpler, fast style sheet for
on-line display.
SOME EXISTING MODELS
There are two models that suggest itself for the on-line style sheet
language. Neither can be adopted without changes, though, since they
are primarily paper-based. One is TeX, the other DSSSL. As a
contrast, I added a third model that is very simple and very much
stream based. This `stream model' is implicit in a number of recent sty=
le
sheet proposals, see
<http://info.cern.ch/hypertext/WWW/Style/Welcome.html>.
* TeX
TeX uses a boxes and glue paradigm. Boxes are rectangular only and
they come in two flavours: horizontal, where the contents are placed
from left to right; and vertical, where the contents are placed top
to bottom. They can be arbitrarily nested. Glue can optionally be
put between boxes, to keep them at a fixed distance or to constrain
their distances to a certain range. The size of a box is normally
determined by its content, but TeX defines splitting operations that
create two boxes from a single one that is too large, with the first
one having a specific size.
There is no static page model, instead a page is constructed by an
algorithm that the designer must write. To that end, TeX defines its
own programming language. The algorithm constructs a box (of course)
by combining some boxes and splitting others. This model is very
flexible, but it relies on a large library of subroutines to make it
workable. (LaTeX is one such library).
Because of the procedural approach and the tremendous flexibility in
the possible algorithms, a page is never ready until the page
building routine has finished. Although data is processed in the
order that it arrives, it must be kept in its several (numbered)
boxes, until enough material has been assembled to fill one
page. So, if we want our style sheet processor to produce output
while data is still coming in, we'll have to view the formatted
document as a sequence of pages.
* DSSSL
The DSSSL model is based on a static page model and a large
collection of `flow objects'. The page model specifies the size of
the page and indicates various regions in it (headers, footers,
float areas, footnote areas). The page is then filled with flow
objects, each flow object being labeled to indicate into which
region of the page it should go. Some flow objects can also be
nested, because they have one or two labeled sub-regions into which
other flow objects can be put.
Flow objects are at a higher level of abstraction than TeX's
boxes. They try to catch intuitive types of text blocks, such as a
paragraph, a labeled item, a text string with a specific font, a
string of R-to-L text in the middle of L-to_R text, a leader,
etc. Each object has its own set of parameters, e.g., a paragraph
has indents (left, right, first line), line spacing, alignment (of
the paragraph within its column) and justification (of the text
inside the paragraph).
Although DSSSL doesn't specify how flow objects should be put into
the page in the same detail as TeX does (making it possible for an
implementation to compromise the quality for the sake of
efficiency), it is still difficult to produce output before the page
is full. Some relief may be had in restricting DSSSL to a carefully
chosen subset, DSSSL Lite is an attempt at this.
* Stream model
As a contrast, consider a third model, that basically outputs text
as soon as it fills a line. The way the text is output is modified
occasionally, to change the font, indent, vertical spacing,
etc. With a few exceptions, this model needs only a single buffer
(one line's worth) and a stack of formatting attributes. There are
no nested elements, only atomic ones (letters, whitespace, icons,
embedded external objects, and interaction elements).
The model supports only layouts that fill the page from top to
bottom, though within a line text may be either L-to-R or R-to-L. At
significant points in the data stream, the line filling method and
the text attributes change: the start of an SGML element pushes a
new set of margins, fonts, colors, etc. The end of the element pops
them again. Extra vertical space can also be inserted at those
points.
Floating images can only float to the left or right margin, they
cannot be moved to the top or bottom of the page. Similarly,
footnotes might be rendered as pop up boxes, but they cannot move to
the end of the text. For tables, either an exception to the rule
must be allowed (buffering the table until the end of the table is
found), or dynamic widening of the columns must be left out.
The `page' has a known top, but no bottom. It has left and right
margins, but the margins may change after every line, either because
a new formatting instruction is executed, or because a floating
object is inserted into the margin. The current margins are always
known, however, and decisions may be based on them.
For HTML, such a model may well be adequate. HTML contains text more
or less in the order that it appears on the page, but for general
SGML it may be too limited. E.g., a caption that is at the end of a
table in the SGML stream cannot be rendered at the top of the table
and two elements that are far apart but linked together (by means of
an IDREF) cannot be displayed together.
VIEW OF SGML
In DSSSL, the SGML document is seen as a tree of elements (other
trees can also be recognized: entity structure, marked section
structure, etc., but are less prominent; in DSSSL Lite they are
absent). The basic idea is that an element results in a flow object
and the children of the element result in nested flow objects.
In the stream model, on the other hand, the linear structure of SGML
is the most important aspect and the beginnings and endings of
elements are signals that occur in some order and change the
formatting algorithm. The tree structure may only be used in the
sense that the number of unclosed element can be a factor in
selecting a formatting rule.
Whatever the primary view of SGML will be, the formatting must be
based on an abstract view of the data content (ESIS), not on the
actual representation. That means that the style sheet language
doesn't have to deal with things like omitted tags, general
entities, marked sections, etc. A question is if PI's are needed,
but I hope not.
CONCLUSIONS
[The conclusions are all in square brackets, since I can derive no
conclusions other than my own preferences. I think the stream model
is adequate. Compared to what we have now it is a large step
forward. When I want to print, not view, a document I map it to TeX
and I foresee that I will continue to do so until a formatter comes
around that delivers better quality.]
[Of course, there will be documents that can only be displayed
inadequately with a such a simple style language, but for such
documents there will probably be better (external) viewers that can
do the job, though slower.]
PS
[The earlier article on addressing dealt with ways to link parts of
the text to parts of the style sheet. It didn't say anything on how
the style sheet as a whole is associated with a document. It has
been suggested that the LINK tag be used for this, but on thinking
on it I found that that was not a good idea. One reason is that it
doesn't solve the problem for other formats than HTML, another
reason is that the LINK tag occurs in the middle of the document and
formatting should have started before that. Maybe a header line or
parameter in the HTPP protocol is better suited for this.]
[The issue of combining several style sheets into one, or overriding
selective parts of it, as in H=E5kon Lie's `Cascading Stylesheets'
<http://info.cern.ch/hypertext/WWW/People/howcome/p/cascade.html>,
is probably more a question of syntax, than of model.]
-- =
Bert Bos Alfa-informatica
<bert@let.rug.nl> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN