Stream-based Style sheet Proposal
Before I can introduce my own syntax, I will have to dismiss :-)
earlier proposals. (Also see HTML
Raisch's proposal of June 1993. Except for minor details, this
would meet my requirements, but I think the syntax can be improved.
- Joe English'
proposal using SGML syntax. (Already withdrawn by the author.)
Everything can be expressed in SGML syntax, but SGML isn't necessarily
the best format for everything.
- DSSSL & DSSSL
Lite by James Clark e.a.. I'm sure DSSSL (or DSSSL Lite) will find
its place in the formatting of complex SGML, despite its shortcomings,
since there simply isn't anything else that's standardized. But for on
the fly (stream-based) formatting, it's unusable. As long as the
on-screen representation of a document maintains (more or less) the
order of the elements in the SGML file, there is no need for the
goal-based model of DSSSL.
Lie's cascading style sheets. This proposal again follows the same
route as 1 and 2 and thereby meets the requirements I set. The syntax
is very close to what I will use below. The ability for the client to
override style sheets in a controlled manner is very appealing, but
unfortunately not as simple as this proposal supposes. Nevertheless,
context-dependent or even weighted overrides are worth investigating
to the Max' by C.M. Sperberg-McQueen and Robert Goldstein. This
`manifesto' contains many sensible words about the deployment of
general SGML on the WEB. For a style sheet language to be practical,
the SGML document must be in the canonical form towards which the
authors have made a start. I guess this defines the border between
documents requiring DSSSL and those that can be formatted `on the
fly': the SGML must be in canonical form and the elements must be in
the right order.
First a note about the syntax I adopted: it is simply the syntax
used by X resource files. The advantages are as follows:
- At least under X, all the routines for parsing and
string-to-whatever conversions are already there.
- It supports the addressing of elements as direct children or
descendants of other elements.
- Except for a few subtleties with inheritance and priorities among
general and specific specs, the syntax is straightforward, very
readable and easy to write by hand.
The subtleties mentioned above involve specifications with
wild cards. There are well-defined rules for them, but a few cases they
may be somewhat surprising. With inheritance I mean the rule that
elements in the SGML document inherit most of the style properties of
the enclosing element. This must be distinguished from the properties
that are shared because they have a wild card in them.
In general all element names are in uppercase, attribute names are
also in uppercase and preceded by `
!', ID's are preceded
by an `
@', property names consist of lowercase letters.
In certain contexts, property names can be preceded by
All of the properties can have an explicit value, an attribute
reference (with `
!'), or a reference to another property
(indicated by an initial `
$'). An attribute or property
is replaced by its value. For a property, this is the value of the
property in the enclosing element (otherwise the order of evaluation
would matter). If a property has an illegal value, the property is
regarded as not being present.
The value may also be a built-in function. The only function
defined so far is `
@ifmatch(A, B, C,
D)', where A is the name of an attribute (with
!') or property (with `
$'), B is a
regular expression, C is the value of the property if A
matches B, D is the value otherwise. D may be
Below is a list of style properties. I've tried to make the list as
comprehensive as possible, but I'm sure there are omissions or things
that are better expressed in different ways. For each property there
is a short explanation of the semantics and the way it is inherited in
sub-elements. If a property is inherited, it means that the final
value of the property is inherited. E.g., if a property is given as
*FOO.justify: !ALIGN' and attribute
FOO has the value `
left', then all
FOO are left aligned, it doesn't matter
if they have an
ALIGN attribute of their own.
Vertical space is, unless explicitly stated otherwise, expressed
in units equal to the normal line height of the default (initial)
font. Thus, these heights are independent of the actual font size or
leading. For X, this line height would be the sum of the font's
overall ascent and descent.
Horizontal space is measured in ems of the default font. For an X
font, this would be the value of the
(if indeed the default font has one, otherwise a suitable estimate).
- (Boolean) Indicates that the element has no
end tag. The formatter will in effect open the element and then
immediately insert a virtual end tag and execute that. Not inherited
- Font size, absolute or as an increment to
the inherited size, the two are distiguished by the presence/absence
of an initial `+' or `-'. Example: assume initial size is 0; if
<SUP> has property `
*SUP.size: -2' it
would be -2 after
<SUP>; after another
<SUP> it would be -4. Of course, browsers only have
a limited set of sizes and -4 may well turn out the same as -2. This
property is not inherited (but the resulting cumulative size is!)
- Font family. There are four families:
normal, alt, tt, and sym. `normal' is useful for running text. `alt',
if different from `normal', is suitable for titles. `tt' is a fixed
width font. `sym' is for special symbols that are not in any character
set (called WWW-icons, such as folder and audio). Inherited.
- Font family. This is the name of a
specific family, such as Bembo, Gill Sans, Univers, Garamond, etc.
Takes precedence over `family', but only if the browser is able to
provide the font. Inherited.
- A number selecting the level of
emphasis. Browsers are free to implement this any way they like, but
they must support at least levels 0 (of course!), 1, and 2. Inherited.
- (Boolean) Select oblique or italic font.
Overrides `emphasis'. Note: there is no way to select slanted rather
than italic as in TEX, is this needed? Inherited.
- (Boolean) Select bold font. Overrides
- A number giving the number of lines
under the text. Overrides `emphasis'. Inherited.
- (Boolean) a line through the text.
- Colour of foreground, using X
- Colour of background. The value
`transparent' is also allowed. Inherited.
- Extra vertical space to put between
lines, relative to the default line height of the actual font in the
element, Thus, 1.0 means double-spaced lines, whatever the current
font size. Inherited.
- Amount to raise (or lower, if negative) the
text above the baseline. The value can be ...-2, -1, 0, 1, 2,..., to
indicate the positions (The exact positions in pixels are a property
of the font.) This property automatically selects an appropriately
smaller font size, so no `size' is needed (unless one wants an even
smaller font). Inherited.
- (Floating point number) Minimum amount
of whitespace above the element. (Implies a paragraph break.) The
whitespace is not added to the vertical space already there, but the
space becomes the maximum of the existing space and the new. Example:
*OL.prebreak: 1.0' and `
would cause the first
<LI> to be 1.0 line (maximum
of 1.0 and 0.5) below the previous paragraph. Not inherited.
- Minimum amount of whitespace below the
element. Not inherited.
- (Floating point number) The presence
of this property causes a horizontal rule to be inserted above the
element, followed by the given amount of whitespace. The rule appears
after any `prebreak'. Not inherited.
- Insert the given amount of whitespace
and a horizontal rule below the element, but before any `postbreak'
(implies a paragraph break). Not inherited.
- Thickness of the rule, in line
heights. Only meaningful if `rulebefore' and/or `ruleafter' are
- (Floating point number) Increment to
the current left margin. Implies a paragraph break. Not inherited (but
the cumulative margin is!).
- Increment to the right margin. Not
- Width of the paragraph in ems. This
implies a paragraph break and overrides `rightindent'. Not inherited.
- Alignment mode for the paragraph. The
presence of this property implies a paragraph break). Possible values
are `left', `right', `full' and `center'. Default value is `full'.
Inherited (but not the implied paragraph break).
- There are three tracks: the main one, one
on the left and one on the right. Text (or images) can be `floated'
against the left or right margins, causing the main track to flow
around it. Values for this property are: left, right, normal. Implies
a paragraph break. Inherited (except for the implied paragraph break).
- (Floating point) Indentation of first
- (Boolean) Suppresses `parindent' on the
next paragraph after this element. Not inherited.
- Start a new paragraph with a label sticking
out into the left margin. Values are: A, a, 1, I, i, bullet, square,
-, *, names of symbols (resp. auto-numbering uppercase letters,
lowercase letters, Arabic numbers, Roman numerals, lowercase Roman
numerals, bullets, squares, dashes, asterisks, WWW-icons). Not
- (Boolean). Text of element is not displayed.
- (Boolean). Text of element is added to
document's title. Inherited.
- URL of something to display in-line at the
start of the element. Not inherited.
- Extra space to add above and below an inline
object. Only useful in combination with inline. Inherited.
- Extra space to add left and right of an
inline object. Only useful in combination with inline. Inherited.
- (Boolean) A click on this element should
generate a URL that includes the coordinates of the click, relative to
the upper left corner of the in-line illustration. Only useful in
combination with inline and anchor. Inherited.
- Vertical alignment of an inline object.
Possible values: top, bottom, middle. Not inherited.
- Height of an inline object in pixels.
Takes priority over whatever the inline object itself suggests for a
height. Not inherited.
- Depth below the baseline of an inline
object, in pixels. This overrides `valign'. Not inherited.
- Width of an inline object in pixels. Only
meaningful in combination with `inline'. Not inherited.
- (Boolean) The element is replaced by a
marker or button, which, when pressed, unfolds into the contents of
the element. Depending on the browser, this may be implemented as a
pop-up box, a new window, or expanding text. Not inherited.
- Possible values: top, bottom, left,
right. The contents of the element should be rendered as a caption and
positioned in the indicated position. The object which it is a caption
for can be found by looking for an `inline' or `table' property on the
element itself or its ancestors. Not inherited.
- The (unique) ID of this element. This value
will nearly always be an attribute reference, such as `!ID'. Presence
of this property will cause the formatter to look for additional
property specifications starting with this ID. Example: if `
!ID' works out, after resolving the attribute, as `
p101', the formatter will look for `
@p101.family', etc. Not inherited.
- (Boolean). Spaces and line breaks are
not removed. Spaces have fixed width, REs (record ends) cause a line
break in the text. If the current value of `justify' is `full', it is
treated as `left' instead.
- (Boolean) Don't break lines. If combined
obeyspaces, REs are treated as single
- Text to insert just before the text
of the element, after any `parindent'. Not inherited.
- Text to insert after the text of the
element. Not inherited.
- Causes enough vertical space to be inserted
to end up below any floating figure in the left, right, or both side
tracks. Implies a paragraph break. Possible values: left, right, full.
- Contains the URL of which this element is
the source anchor. Inherited
- (Only meaningful in combination with
`anchor') Indicates that the anchor is a hotspot in the inline image
of the element or one of its ancestors. Possible values: rectangle,
circle, polygon. Not inherited.
- Coordinates of the hotspot. Only
useful in combination with `anchorshape' and the interpretation
depends on the value of that property. Not inherited.
- (Boolean) Indicates that the element
constitutes a table. Not inherited.
- (Boolean) Indicates that the element is
a table row. It is possible for an element to be both a `table' and a
`tablerow'. If neither the element itself nor one of its ancestors has
the `table' property, `tablerow' has no meaning. Not inherited.
- (Boolean) Indicates that the element
forms one or more cells in a table. An element can be both a
`tablecell' and a `tablerow'. If neither the element itself nor one of
its ancestors has the `tablerow' property, `tablecell' has no meaning.
- The table cell spans the indicated number
of rows. Only meaningful in combination with `tablecell'. If not
present, 1 is assumed. Not inherited.
- The table cell spans the indicated number
of columns. Only meaningful in combination with `tablecell'. If not
present, 1 is assumed. Not inherited.
- Lines around the table cell. Possible
values: any sequence of zero or more words from `left', `right',
`top', `bottom', `border'. `border' is equivalent to `left right top
bottom'. Inherited (but only results in any visible effect in elements
with the `tablecell' property). Default is no frame. Not inherited.
- (Boolean) the text in this element may
be hyphenated at line breaks. Initial value is true. Inherited.
- (ISO code for a language) This may
influence the hyphenation and maybe some other things (such as the
style sheet itself). Default is US English. Inherited.
- Target of a hyperlink (the fragment-ID of
a URL). Not inherited.
- The contents of the element are a
style sheet, applicable to the rest of the document. Possible values
are: `merge', `replace' and `override'. Any other value means that the
contents are not a style sheet. `Merge' means that the style rules are
added to the existing style, with the existing style taking precedence
in case of conflict. `Override' also adds the two together, but gives
precedence to the new rules. `Replace' completely removes the old
style sheet and uses the new one instead. Inherited.
Here is part of a style sheet for HTML:
! Style sheet for HTML documents
! Create a default margin of 3 em
! <H1> is bold, centered, 2 sizes larger than the surrounding text,
! with lines above and below.
! <H2> is bold, 1 size larger, sticking out into the margin,
! not justified and it has a line above it
! <H3> is italic, 1 size larger, in left margin
! <H4> is bold
! <H5> is bold and run-in (i.e., no postbreak)
! <H6> is italic and run-in
! <P>. Note absence of prebreak: because H5 and H6 are run-in
! Various character-level elements
! <BR> forcedly break a line. Flush as in Netscape
! <WBR> is another un-SGML-like element from Netscape
! (&sbsp; doesn't exist, I've made it up, cf. ­)
! <A> is a hyperlink
! <IMG> in-line or floating illustration (Note double use of ALIGN)
*IMG.ismap: @ifmatch(!ISMAP, "ISMAP", true, false)
! if images are not displayed:
! *IMG.insertbefore: !ALT
! <HR> horizontal rule
! <PRE> preformatted text
! <OL> has numbered items <LI>: 1.A.I, bullets elsewhere
Linking to style sheets
Some problems remain: how are style sheets associated with
documents? This is outside the scope of this article, but I would like
to offer some possibilities:
- In the LINK tag of HTML. This is unsatisfactory for several
reasons: (1) it is too late, the document has already started
before the link is found; (2) it doesn't work for non-HTML.
- In a new header line of the HTTP protocol. This is better,
but it relies on HTTP being used.
- As part of a MIME/multipart document.
- In the URL. A bad idea, not only because the style doesn't
really `belong' to the document, but also because the URL would
become too long.
- The other way round: a hyperlink contains not the URL of the
document, but of its style sheet, which in turn references the
document (in a new `document' property).
- As an attribute of A: <A HREF="doc.html" STYLE="doc.sty">
As said earlier, there must be some way for the user to selectively
override part of a style sheet. To keep the rest of the style sheet
intact, it may be necessary to introduce conditionals into the syntax:
! Effect of `delay image loading' on FIG element
! Indentation and justification made dependent on window width
! Use colours only if on colour screen
Other output devices
A somewhat related question is: how can the user (or the browser)
select the right style for a particular purpose, such as printing,
on-line display, speech synthesis. These different purposes could be
encoded in the style language (allowing all style variants to be in
the same style sheet) or they could be handled externally, possibly in
the way the style sheet is linked from a document.
If a style sheet is to work as intended, the browser must ensure
that the proper nesting of elements is maintained. The parser must
insert missing elements. A formatter that doesn't maintain a parsing
context based on the HTML DTD and only formats the elements that are
named explicitly in the text, will give strange results.
If the document is not coded in HTML, but in some other SGML
format, the formatter has to assume that all tags are present, except
perhaps for a few closing tags that can be inferred from the rule that
elements must be properly nested. This is the only rule that the
parser can use.
Dimensions have implicit units (ems, line heights, pixels)
depending on context. Maybe a notation with explicit units should be
allowed as well.
There are still some properties missing:
- background colour/pattern, not just behind the text, but behind an
- change bars and other vertical lines
- language-dependent layout (hyphenation, quotes)
- overlapping elements, overlays