These may be used to construct a semi-declarative stylesheet language; in a more imperative style, they can be regarded as variables instantiated for each element type. Notation is not specified here, but various options are obviously suitable. In list of primitives, I use functional notation for functions; in the examples below, I use Scheme/Lisp style.
TRUE, block to ???
These apply only if
block=TRUE. If we
use the alternative formulation, then
we have the following cases:
normal | lg | vlg | sm | vsm | huge
roman | italic | bold
normal | underlined | redlined
Or possibly allow association of arbitrary names with a font family, style, treatment, etc., and then simply specify a font-name for each element (more or less like GML).
All variables can also take keyword
INHERIT) as value.
Default value is
and low-level browsers may accept no more.
Higher levels will allow attribute values and string literals. Even
higher levels will allow arguments to content and attval indicating
which element node is concerned, using tf syntax or a derivative, e.g.:
attval('TYPE',prev(1,'P'))-- i.e. attribute value of type on left sibling with gi of P
Possible style-sheet primitives:
a (anchor) element has attribute href, and is formatted in blue:
(style a (block #f) ; format as inline phrase (color blue) ; in blue if you've got it (click (follow (attval 'href))) ; and on click, follow url
It's not clear what to do about low-level browsers which don't support attribute-value extraction; perhaps a special form is needed to allow a definition like:
(style a (block #f) ; format as inline phrase (color blue) ; in blue if you've got it (click 'follow-URL 'HREF)) ; and on click, follow url
p (paragraph) has blank line above, prints smooth L and R, with initial indent and last line flush left:
(style p (block #t) (shape 'normal-para) (vspace '0.5l '0))
h1 (chapter title) has big vertical space, prints very large, respects line breaks
(style h1 (block #t) (vspace '24pt '8pt) (shape 'centered) (font-size 'vlg) (font-style 'bold) (flow #f))
Miscellaneous other element types, with formatting as described in the HTML spec:
(style address (font-style 'italic) (block #t) (shape 'flush-left) (flow #f) (margins '+10pica '0)) (style blockquote (margins '+10pica '-10pica) (block #t) (shape 'block-para)) ; alternative block quote for VT100s etc.: print each line preceded ; by > (style blockquote (margins '+5 '0) (block #t) (shape 'netnews-quote)) (style h2 (block #t) (vspace '12pt '8pt) (shape 'flush-left) (font-size 'lg) (font-style 'bold) (flow #f)) (style h3 (block #t) (vspace '8pt '8pt) (shape 'indent-left) (font-size 'lg) (font-style 'ital) (flow #f)) (style h4 (block #t) (vspace '8pt '8pt) (shape 'indent-twice-left) (font-size 'normal) (font-style 'bold) (flow #f))
Fallbacks are probably best handled with a combination of
conditionals and system-set parameters describing what is supported
and possibly what user's or implementor's preferences are, so as to
allow statements like '
if color is supported, then color=blue
and font-style=inherited, else font-style=italic' and '
multi-column is preferred, then ... else ...'
Variables pose a language design problem: if they are fully supported, e.g. in a macro scripting language like tcl or Scheme, there is no reason to use anything but the normal assignment syntax. Low-end implementors may balk, however, at providing full support for variables and arithmetic, so we might have to extend the Actions section above to accept actions like: