Addressing in style sheets

Bert Bos (bert@let.rug.nl)
Wed, 9 Nov 1994 16:53:22 +0100 (MET)


Message-Id: <199411091553.AA047846402@freya.let.rug.nl>
From: Bert Bos <bert@let.rug.nl>
Subject: Addressing in style sheets
To: www-html@www0.cern.ch (* WWW/HTML discussion list )
Date: Wed, 9 Nov 1994 16:53:22 +0100 (MET)

I've been thinking about a good syntax for style sheets, but I
couldn't decide on one. To a large extent, the syntax is arbitrary
anyway. But I did come up with a few requirements.

We'll need to discuss at least three issues:

  ADDRESSING:	the `left hand side' of the style rules; specifies
		what part of a doc is affected by a rule (see below)

  FEATURES:	what aspects of a design can be specified (font size,
		colour, frames, alignment, background, etc.)

  MODEL:	feature semantics are defined relative to a conceptual
		model (e.g. TeX's boxes & glue, DSSSL's flow-objects)

Addressing needs to be defined separately for each input format, the
other two apply regardless of the source format.

Here are the possibilities for addressing in SGML, partly borrowed
from HyTime and DSSSL. [I've added my opinions in brackets.]

NB. I've omitted non-ESIS information: addressing is only possible on
a `canonical form' of the SGML document (for example, you cannot
select things based on whether it was quoted with single or double
quotes, whether it was the first thing on a line, whether it was in a
marked section or not, or whether is was inside a comment.)

  I. Granularity - the smallest addressable units

    a. SGML elements
    b. sentences
    c. words
    d. letters

    [My opinion: The extra complexity needed to address within
    elements is not worth it. When needed, in most cases you can make
    a new document with extra EM tags inserted.]

  II. Addressing - how to identify the affected parts of a doc

    a. by context	enclosing GI, plus zero or more of its ancestors
    b. by attributes	select elements that have certain attribute values
    c. by ID
    d. by location	path from root to element ("5th child of root")
    e. by content	regular expressions ("elts containing big.*book")
    f. combined a-e	("5th word of elt with ID=xxx")

    [Context is the most intuitive, ID is handy for exceptions to a
    default rule, attributes might be useful as well, but maybe they
    can also be moved to the rhs of the style rules.]

    NB. sometimes it is useful to view the GI of an elt as just
    another attribute.

  III. Notation - how to represent the addresses

    a. identifiers & numbers
    b. regular expressions

    1. HyTime, DSSSL, FOSI
    2. new syntax, such as the one from the `cascading style sheets'

    [HyTime is designed solely for embedding addresses in SGML, there
    is no reason to use it `stand-alone'; DSSSL is too complex and too
    procedural for our needs; FOSI, which uses an SGML compatible
    syntax, is too verbose. As far as I know there is no suitable,
    standardized candidate, so we have to make our own syntax.]


Bert
-- 
___________________________________________________________________________
####[ Bert Bos                     ]####[ Alfa-informatica,           ]####
####[ <bert@let.rug.nl>            ]####[ Rijksuniversiteit Groningen ]####
####[ http://www.let.rug.nl/~bert/ ]####[ Postbus 716                 ]####
####[                              ]####[ NL-9700 AS GRONINGEN        ]####
####[______________________________]####[_____________________________]####