Re: Some comments on Style sheet syntax.

Hakon Lie writes:
 |
 |Peter Collinson writes:
 |
 | > I have been encouraged to post to this list by Hekon Lie. I doubt
 | > that I can spare time to join your discussions.
 |
 |Thanks for posting. My comments follow:
 |
 | > I think that the current syntax is far too weak and will be easy to get
 | > wrong. It's also fussy and not easy to use. I dislike the colon syntax -
 | > it's going to be hard to implement because you have to keep a definition
 | > 'open' because you can add to it at any time. It's going to be
 | > impossible for the writer to KNOW what is on force at any one point in
 | > the document anyway.
 |
 |One of the fundamental features of the Cascading Style Sheet proposal
 |is that several style sheets may influence the presentation. So, the
 |writer (I assume you refer to the style sheet writer) will never "KNOW
 |what is on force", but is given a reasonable chance to influence it.
 |
 |The little language we're descibing is not a programming language. I
 |like to think of the style sheet mechanism as a constraint solver: one
 |throws weighted wishes into it, it resolves any conflicts and outputs
 |a value for the browser to use. So, to a certain extent it's
 |fussy, yes. But:
 |
 |  "Traditionally, ambiguity in parsing is something to be
 |  avoided. However, to support a creative process, this may not be the
 |  case. Ambiguity should be viewed as beneficial and something that
 |  needs to be maintained until later design decisions have been able to
 |  disambiguate the designer's intention."
 |
 |  (From Kent Wittenburg and Louis Weitzman's paper: Automatic
 |   Presentation of Multimedia Documents Using Relational Grammars
 |   ftp://flash.bellcore.com/pub/rl/docs/rg-for-ap5.ps.Z)

Be careful with that quote, it can easily be abused! Of course a
writer/designer benefits from ambiguity (or more friendly: postponed
decisions, parallel options, disregarded exceptions). I doubt if he
can do without, but the ambiguity is all in his mind (or in the
comments), the resulting style sheet is not ambiguous.

I agree with Hakon that the style language should (and does) support
this creative process in its choice of syntax. Hakon calls it a
constraint solver, I like to think of it as a set of normal cases with
exceptions. As a designer, you don't *have* to divide the presentation
for one class over several lines in several files, but the ability to
do so provides an opportunity for defining (or borrowing via a URL!) a
base style and then varying it a little for each document.

Of course, nothing is fixed about the delimiters of the language. If
people appear to understand a curly brace but not a colon, then that
can be changed. But the `cascading' model is IMHO too useful to drop.

 | > So the notion of
 | > 
 | > 	HTML_ELEMENT : SPECIFICATION
 | > 
 | > would be better rendered as
 | > 
 | > 	CLASS_NAME { SPECIFICATION }
 | > 
 | > where SPECIFICATION may be a multi line set of elememts. This makes
 | > a complex element like the EM.first much more intuitive (and easier
 | > to parse too). The use of braces is important psychologically for
 | > the writer - and will also aid in parsing the specification.
 | > 
 | > first {    font.style = dropped big-initial small-caps
 | > 	   font.size = 12pt
 | > 	   undersize.font.size = 12pt
 | >    	   oversize.font.size = 24pt   // assuming leading is zero
 | > 	}
 | > 
 | > Now I can use the 'first' class anywhere - and that's the next key
 | > point---
 | > 
 | > The style sheet should ONLY defines CLASSES - how they are applied
 | > should be left to the document.  If the attributes are not relevant then
 | > they can be ignored.
 |
 |If I understand you correctly, you propose to take out the addressing
 |part of the style sheet language and use the CLASS attribute in the
 |HTML document to select a group of style properties. This could work,
 |yes, but you don't simplify the mechanism -- you just move markup into
 |the HTML. One of the goals of the CSS proposal is to minimalize
 |interference with HTML, and to be able to apply a style sheet to an
 |existing document without changing it. You open up for a similar
 |functionality by addressing a default class:

I've been thinking about giving CLASS a more important role as well,
but I don't want to go as far as Peter. In fact, I want to give CLASS
and GI *equal* status: you can base the address on CLASS, GI, or
both. (Hakon, did you see my mail about this?)

Hakon is right, of course, that you can't base a style on CLASS
attributes if the document doesn't contain any. And I predict that
most documents won't.

 |
 | > If I set a CLASS then that class should remain in force until
 | > explicitly reset - you need to adopt some syntax like
 | > <P CLASS=default>
 | > to reset things back to the currently prevailing defaults. Maybe
 | > default should be an addressible class anyway so that that can be
 | > altered.
 |
 |However, if there is only one default class, all elements will look
 |the same (unless, of course, you subclass them). No? I you, on the
 |other hand, have several default classes, on what basis will you pick
 |one?
 |
 |Instead of making subclassing mandatory, the CSS proposal takes
 |advantage of the existing "subclasses" (H1, P etc) and overlays styles
 |based on these. For me, that's intuitive, and Peter's extra level of
 |indirection is not. What do other people think? (I fear my intuition
 |is somwhat damaged after thinking about these issues for some time :-)

Although SGML does have a method for setting an attribute once and
keeping it until explicitly changed, I would argue that it shouldn't
be used. It makes it harder to parse the document and it makes it
harder to edit it (since it crosses the hierarchical nature of the
document). A better way is to set the CLASS of a common ancestor. That
makes the attribute easy to find and the document remains a tree.


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

Received on Wednesday, 26 July 1995 09:25:50 UTC