Hakon's latest CSS draft and Benjamin Sittler's message about
selecting fonts (the one that started the discussion about
TEXT/STRING/ELEMENT/C/FONT/PHRASE :-)) prompted me to write some
comments. The short comments are below, more worked-out texts can be
found in `SGML-Lite'[1] and `text and font properties'[2].
** Element grouping
The section `element grouping' can be removed. It is repeated under
`Shortcuts'.
** Classes
Addressing based on other attribute values than CLASS is very
useful. For example, we only want to underline an A if it has an HREF,
not if it has a NAME.
Another reason is that we need to be able to inspect attribute values
in order to translate formatting instructions (ALIGN=LEFT,
CLEAR=RIGHT, etc.) to style properties. E.g.:
P[CLEAR=RIGHT]:flush=right
(or a similar syntax.)
I've created a formal grammar for this part of the style sheet
language [3], maybe some people can comment on it?
** Default properties and inheritance
Whether the default properties are inherited or not depends on the
property. Making it depend on the element instead is rather
counter-intuitive: why should an EM inherit from a P, but a P not from
a NOTE?. Also, for some properties inheritance is never useful: e.g.,
break.before is defined for a P but an EM shouldn't inherit it.
Also, in my grammar there is an important difference between different
senses of `document-wide defaults' in the case of inherited
attributes: Assuming text.color is an inherited property,
*HTML:text.color=(0,0,0.5)
means that the color starts out as blue (instead of the application
dependent default), but otherwise inherits down the tree normally. On
the other hand:
*:text.color=(0,0,0.5)
applies the color to every element that doesn't have a text.color
property, thereby disabling inheritance!
** Context-sensitivity
Why are sequential patterns restricted to children of BODY? How about
non-HTML documents? Also see [3] for a syntax without parentheses.
** Addressing environment properties
A UA can use environment variables, but what does it mean to assign
values to them?
The three examples given are rather strange:
- HTML-SOURCE: I assume this means that the browser is asked to use a
certain font when it displays the source of this document
(view-source command). I don't think this is under the control of
the HTML-viewer. Viewing the source is a form of debugging, how it's
done is strictly between me and my browser, I certainly don't want
the author of the document to interfere.
- CLIENT-WINDOW: a document can express a desired text width and
height, and my browser will add the appropriate scroll bars, but
allowing the document to change the window size is not an
option. (If a browser implemented this, I suspect it will be very
unpopular.)
- CLIENT-WINDOW font: what font is meant here? Is this different from
"*:font" or "HTML:font"?
** Font
See [2]
** font.size
If we allow absolute sizes like point, the author must be aware that
the UA will only use these sizes as relative to a certain unit that
depends on the occasion. If I project a page on a video wall, my
software will interpret `point' to be about a centimeter, but when I
print it on a 35mm slide, a `point' will be more like 0.01 mm.
A unit like `pixels' that is neither relative nor absolute will be
even more problematic, since no relation to any other size can be
assumed. I guess the definition of `pixel' will be: in the case of an
application that shows the document at about arm's length, a `pixel'
is a unit of length between approximately 0.20 and 0.35 mm chosen by
the application so that n pixels is visually different from (n+1)
pixels, for n = 0, 1, 2,...N; other types of applications can extend
this definition as appropriate.
** font.family
The question of font substitution is far more difficult than just
giving a list of alternatives. When the font for P is replaced, then
maybe I also want a different font for PRE. Maybe we need font sets,
that can be replaced as a whole. (The current discussion about
conditional styles and property grouping applies to this.)
Also, in the case of Unicode document, we will have to use the list of
fonts not as alternatives, but as fonts covering different ranges of
character codes.
** font.style
(Also see [3]) Underline, overline, etc. are not font styles, I would
call them text styles. Likewise for inverse, (inverse is an
abbreviation for color & background, isn't it?), blink, lowercase and
uppercase.
Serif/sans serif is implicit in the family. Old/modern may be implicit
in the family or can be handled via Benjamin Sittler's encoding
vectors.
What are big-caps?
Big-initial and dropped are paragraph styles, not font styles.
** Oversized and undersized
The size of the small-caps is not an independently selectable
property. If you select a font size, then the size of the
corresponding small-caps font is fixed.
** Links
Setting per-element link properties can also be done with
context-dependent addressing. If a link in a P should look differently
from a link in an H1, one can use a syntax like:
*P*A: text.color = #00F # A inside P
*H1*A: text.color = (1.0, 0.0, 0.0) # A inside H1
The style sheet should not only tell how a link looks, but also what
the link is. From looking at the SGML source a UA cannot know what
attribute or element contains a link.
The same is true of in-line images and other inclusions: the style
sheet will have to tell the UA that the image can be found by
following the URL in the SRC attribute.
link.color is meaningless: a link is not something that has a
color. It may be a piece of text, an image, a clickable image, or
something else. What would link.color mean if the link is actually an
MPEG movie? But it is of course possible to put a frame around an
inclusion (IMG, FIG or otherwise).
(Giving an A different colors based on the REL attribute is a more
interesting possibility.)
** List numbering
How is HTML3's CONTINUE attribute handled? It requires a counter that
is not automatically reset at the start of an element. (Also see [4].)
** Color
The style sheet spec could include a (short) list of color names that
UA's are expected to know.
** Arithmetic
The meaning of `P:font.size=H1.foo[font.size]' is unclear. This
suggests that you can compute the font size of an element H1 with
class foo, but I don't think that is possible in general. There may be
several rules for H1 and you may need to know its context and
attributes before you can tell its font size.
The arithmetic should probably be resticted to the attributes of the
element itself and the properties of the element's parent. A case can
be made for using the attributes of ancestors, but most of that can be
catered for by conditionalizing on the attributes instead:
*p: font.size = font.size * 0.8 # Use parent property
*font: font.size = [size] * 0.8 # Use own attrib
*ul[compact]*p: break.before = 0 # Use ancestor attrib
Variables are not needed, since nothing is variable in the style
sheet. Symbolic constants could be useful, though.
** Cascading order
The `application default' is described as `hardcoded'. In fact, it
could be merged with the `reader normal' level and described as `user
configurable fallback values'.
Whether they are taken from the initial page or from somewhere else is
a matter for the UA writer.
** Vocabulary
Do we really need abbreviations? I'm afraid it confuses people rather
than helps them.
** Formatting model
I don't think boxes are the appropriate model. They don't allow
floating images with text flowing around them, they don't express the
behaviour of elements with a line break before but not after them
(e.g., DT and DD), and they don't model the banner (or header/footer)
areas.
Boxes should be reserved for the page model (the outermost level of
page description). The behaviour of the text stream inside the boxes
is better described IMHO by the notion of commands interspersed with
the text: commands to change the font, to change the margins, to
divert the text stream into another box, to skip vertical space, etc.
In other words, the formatted text stream is not a hierarchy like the
SGML stream, but a linear sequence of letters and commands that change
the layout from that point on until the next command (or until a
pop-command?). Note that this is not a real format! Just a conceptual
model in order to explain the semantics of each property. If needed,
an application can use DVI or PostScript or anything else as a
concrete format.
Bert
PS. I have found another alternative to TEXT, C, FONT, ELEMENT, PHRASE and
STRING, viz. in the TEI DTD: RS (for `Referring String') :-)
[1]: <http://www.let.rug.nl/~bert/Stylesheets/SGML-Lite.html>
[2]: <http://www.let.rug.nl/~bert/Stylesheets/textfont.html>
[3]: <http://www.let.rug.nl/~bert/Stylesheets/addressing.html>
[4]: <http://www.let.rug.nl/~bert/Stylesheets/unsolved.html>
--
Bert Bos Alfa-informatica
<bert@let.rug.nl> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN