A model for on-line formatting with style sheets

Bert Bos (bert@let.rug.nl)
Tue, 20 Dec 1994 16:15:01 +0100 (MET)


Message-Id: <199412201515.AA073186502@freya.let.rug.nl>
From: Bert Bos <bert@let.rug.nl>
Subject: A model for on-line formatting with style sheets
To: www-html@www0.cern.ch (* WWW/HTML discussion list )
Date: Tue, 20 Dec 1994 16:15:01 +0100 (MET)

A MODEL OF ON-LINE FORMATTING

  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